cmd/compile: failure to optimize away temporary variable #8525
Labels
Milestone
Comments
CL https://golang.org/cl/126160043 mentions this issue. |
This affects 6g and 8g only. 5g yields the same output for each:
"".f t=1 size=16 value=0 args=0x4 locals=0x0 leaf
0x0000 00000 (8525.go:8) TEXT "".g+0(SB),16,$-4-4
0x0000 00000 (8525.go:8) FUNCDATA $2,gclocals·a7a3692b8e27e823add69ec4239ba55f+0(SB)
0x0000 00000 (8525.go:8) FUNCDATA $3,gclocals·3280bececceccd33cb74587feedb1f9f+0(SB)
0x0000 00000 (8525.go:8) MOVW $0,R0
0x0004 00004 (8525.go:9) MOVW $2,R0
0x0008 00008 (8525.go:9) MOVW R0,"".~r0+0(FP)
0x000c 00012 (8525.go:9) B ,0(R14)
There appears to be a missing constant propagation (MOVW $0,R0 could be excised), but
that's a different issue.
|
|
This issue was updated by revision be2ad1d. Some temporary variables that were fully registerized nevertheless had stack space allocated for them because the Addrs were still marked as having associated nodes. Distribution of stack space reserved for temporary variables while running make.bash (6g): BEFORE 40.89% 7026 allocauto: 0 to 0 7.83% 1346 allocauto: 0 to 24 7.22% 1241 allocauto: 0 to 8 6.30% 1082 allocauto: 0 to 16 4.96% 853 allocauto: 0 to 56 4.59% 789 allocauto: 0 to 32 2.97% 510 allocauto: 0 to 40 2.32% 399 allocauto: 0 to 48 2.10% 360 allocauto: 0 to 64 1.91% 328 allocauto: 0 to 72 AFTER 48.49% 8332 allocauto: 0 to 0 9.52% 1635 allocauto: 0 to 16 5.28% 908 allocauto: 0 to 48 4.80% 824 allocauto: 0 to 32 4.73% 812 allocauto: 0 to 8 3.38% 581 allocauto: 0 to 24 2.35% 404 allocauto: 0 to 40 2.32% 399 allocauto: 0 to 64 1.65% 284 allocauto: 0 to 56 1.34% 230 allocauto: 0 to 72 LGTM=rsc R=rsc CC=dave, dvyukov, golang-codereviews, minux https://golang.org/cl/126160043 |
rsc
changed the title
|
Doesn't reproduce with revision b9feb91 |
|
Yes, SSA fixes this. Closing. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'd expect these functions to compile identically: func f() int { a := 2 return a } func g() int { return 2 } They do not (6g): "".f t=1 size=32 value=0 args=0x8 locals=0x8 0x0000 00000 (d.go:3) TEXT "".f+0(SB),4,$8-8 0x0000 00000 (d.go:3) SUBQ $8,SP 0x0004 00004 (d.go:3) FUNCDATA $2,gclocals·a7a3692b8e27e823add69ec4239ba55f+0(SB) 0x0004 00004 (d.go:3) FUNCDATA $3,gclocals·3280bececceccd33cb74587feedb1f9f+0(SB) 0x0004 00004 (d.go:4) MOVQ $2,AX 0x000b 00011 (d.go:5) MOVQ AX,"".~r0+16(FP) 0x0010 00016 (d.go:5) ADDQ $8,SP 0x0014 00020 (d.go:5) RET , "".g t=1 size=16 value=0 args=0x8 locals=0x0 0x0000 00000 (d.go:8) TEXT "".g+0(SB),4,$0-8 0x0000 00000 (d.go:8) NOP , 0x0000 00000 (d.go:8) NOP , 0x0000 00000 (d.go:8) FUNCDATA $2,gclocals·a7a3692b8e27e823add69ec4239ba55f+0(SB) 0x0000 00000 (d.go:8) FUNCDATA $3,gclocals·3280bececceccd33cb74587feedb1f9f+0(SB) 0x0000 00000 (d.go:9) MOVQ $2,"".~r0+8(FP) 0x0009 00009 (d.go:9) RET , There are two inefficiencies in f: A useless stack variable and two MOVQs where one suffices. CL 126160043 will address the useless stack variable. The MOVQs should presumably be handled with a peephole optimization that copies the constant when it has only one subsequent use.The text was updated successfully, but these errors were encountered: