Out of interest, I chased this down a bit using `git blame`. I think the code in its current form (more or less - some constants where introduced later and things where moved around a bit here and there) was introduced here: https://go-review.googlesource.com/c/go/+/10268/ It seems checks from multiple places where consolidated into one. One of these checks was `n.Type.Width > MaxStackVarSize` another was `!(n.Type.Type.Width < 1<<16`), which then got rewritten into `n.Type.Type.Width >= 1<<16` to avoid the negation, which eventually became the code you looked at. Before that commit, it's not clear to me where this specific condition was taken from.
So, from what I can tell, it's an artifact of these two things being written by different people and then evolving over a long time into the same place via a sequence of semantics-preserving small refactorings. I don't think there is a technical reason they should be different but I also assume that it's not worth it to make them the same - it doesn't really matter if we move things to the heap one byte earlier or later, only the order of magnitude is important. But I might be wrong about all of this. I don't really understand the purpose of you diving so deep into the escape analysis behavior and then asking *extremely* detailed questions like this (though I am always curious to see if you could find the answer yourself, which is why I dove into the git history). ISTM if this causes a problem, the best way to address it would be to file a bug. And if it's just curiosity, you can always try and change it and see what breaks. Go has a lot of tests. On Sat, Jun 26, 2021 at 11:52 AM tapi...@gmail.com <tapir....@gmail.com> wrote: > Sorry, a typo in title. It should be "comparison". > > On Saturday, June 26, 2021 at 5:50:55 AM UTC-4 tapi...@gmail.com wrote: > >> >> The code: >> https://github.com/golang/go/blob/cca23a73733ff166722c69359f0bb45e12ccaa2b/src/cmd/compile/internal/escape/escape.go#L2012-L2025 >> >> xxx > ir.MaxStackVarSize >> >> xxx >= ir.MaxImplicitStackVarSize >> >> This leads to the elements of a slice with size as ir. >> MaxImplicitStackVarSize will be allocated on heap, but an array with >> size as ir.MaxStackVarSize will be allocated on stack. >> >> Is this intended? >> >> >> >> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/d26fec6c-03ba-4ea2-aa03-4e47f0980660n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/d26fec6c-03ba-4ea2-aa03-4e47f0980660n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfH-vi9AfOjMwrUKV%3DuwyMW_4Xosk0aFUdUnSbYdAAKiDQ%40mail.gmail.com.
