Inlining is conservative. As well as the size of the code being inlined,
current 40 units (unit has not scale), some operations are not inlined, as
they are considered hairy. switch used to be considered hairy, 1.7 fixed
that, for is still hairy.
On Tuesday, 30 August 2016 15:58:30 UTC+10, Soko
But still question is interesting: why decision is based on source code and not
on instructions size? Both functions likely to produce same assembler code.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop r
I didn't know it has more levels. thanks
On Monday, August 29, 2016 at 6:09:19 PM UTC+3, Sam Whited wrote:
>
> On Mon, Aug 29, 2016 at 9:40 AM, Ariel Mashraki
> > wrote:
> > Can someone please explain why doesn't the f2 function get inlined ?
>
> If you build with m=2 (go build -gcflags -m=2)
On Mon, Aug 29, 2016 at 9:40 AM, Ariel Mashraki
wrote:
> Can someone please explain why doesn't the f2 function get inlined ?
If you build with m=2 (go build -gcflags -m=2) it will spit out a reason:
> cannot inline f2: unhandled op for
(closures with "for" in them apparently can't be inlined)
On 2016-08-29 16:59, 'Chris Manghane' via golang-nuts wrote:
I can't explain exactly because my explanation is likely very flawed,
but the logic you are looking for is
in
https://github.com/golang/go/blob/320ddcf8344beb1c322f3a7f0a251eea5e442a10/src/cmd/compile/internal/gc/inl.go#L186.
Basical
I can't explain exactly because my explanation is likely very flawed, but
the logic you are looking for is in
https://github.com/golang/go/blob/320ddcf8344beb1c322f3a7f0a251eea5e442a10/src/cmd/compile/internal/gc/inl.go#L186.
Basically, labeled loops are not considered "hairy" by the compiler and c
Hello,
Running `go build -gcflags -m` on the given code below will produce:
main.go:3: can inline f1
main.go:24: inlining call to f1
Can someone please explain why doesn't the f2 function get inlined ?
Thanks
package main
func f1() int {
i := 0
loop:
if i > 10 {