Sorry, that we noticed this regression just now but not in September. After Makarov's fix for 61578 ( and s390 regression) we noticed that for attached simple test-case extracted from real benchmark one more redundant move instruction is generated (till 20160202 compiler build): before fix (postreload dump) 86: NOTE_INSN_BASIC_BLOCK 4 40: dx:QI=[si:SI] 41: ax:QI=[si:SI+0x1] 42: {si:SI=si:SI+0x3;clobber flags:CC;} 43: dx:SI=zero_extend(dx:QI) 44: ax:SI=zero_extend(ax:QI) 45: cx:SI=zero_extend([si:SI-0x1]) 46: {di:SI=dx:SI*0x4c8b;clobber flags:CC;} 47: {bx:SI=ax:SI*0x9646;clobber flags:CC;} 48: {bx:SI=bx:SI+di:SI;clobber flags:CC;} 49: {di:SI=cx:SI*0x1d2f;clobber flags:CC;} 50: NOTE_INSN_DELETED 51: bx:SI=bx:SI+di:SI+0x8000 52: {bx:SI=bx:SI>>0x10;clobber flags:CC;} 53: [bp:SI]=bx:QI 96: bx:SI=dx:SI 55: {bx:SI=bx:SI<<0xf;clobber flags:CC;} 57: {bx:SI=bx:SI-dx:SI;clobber flags:CC;} after fix 86: NOTE_INSN_BASIC_BLOCK 4 40: dx:QI=[si:SI] 41: ax:QI=[si:SI+0x1] 42: {si:SI=si:SI+0x3;clobber flags:CC;} 43: dx:SI=zero_extend(dx:QI) 44: ax:SI=zero_extend(ax:QI) 45: cx:SI=zero_extend([si:SI-0x1]) 46: {di:SI=dx:SI*0x4c8b;clobber flags:CC;} 47: {bx:SI=ax:SI*0x9646;clobber flags:CC;} 48: {bx:SI=bx:SI+di:SI;clobber flags:CC;} 49: {di:SI=cx:SI*0x1d2f;clobber flags:CC;} 50: NOTE_INSN_DELETED 51: bx:SI=bx:SI+di:SI+0x8000 52: {bx:SI=bx:SI>>0x10;clobber flags:CC;} 53: [bp:SI]=bx:QI 96: bx:SI=dx:SI 55: {bx:SI=bx:SI<<0xf;clobber flags:CC;} 98: di:SI=bx:SI !! redundnat move 57: {di:SI=di:SI-dx:SI;clobber flags:CC;} In result, we got >3% slowdown on Silvermont in pie & 32-bit mode.
Created attachment 37559 [details] test-case to reproduce Need to be compiled with -O2 -m32 -pie -fPIE. Assume that -march=slm is not needed.
Doesn't seem to happen over here. Can you still reproduce this with trunk? Please post exact arguments to cc1 if it does.
Sorry for a confusion. The bug must be closed as user mistake. 2016-03-07 19:18 GMT+03:00 bernds at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69633 > > Bernd Schmidt <bernds at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |bernds at gcc dot gnu.org > > --- Comment #2 from Bernd Schmidt <bernds at gcc dot gnu.org> --- > Doesn't seem to happen over here. Can you still reproduce this with trunk? > Please post exact arguments to cc1 if it does. > > -- > You are receiving this mail because: > You reported the bug.
Closing then.
Strange, I can still reproduce it: ./cc1.228094 -quiet -O2 -m32 -fPIE pr69633.c -o pr69633.s1 -march=i386 \ -mtune=generic ./cc1.228097 -quiet -O2 -m32 -fPIE pr69633.c -o pr69633.s2 -march=i386 \ -mtune=generic ./cc1.228153 -quiet -O2 -m32 -fPIE pr69633.c -o pr69633.s3 -march=i386 \ -mtune=generic ./cc1.234064 -quiet -O2 -m32 -fPIE pr69633.c -o pr69633.s4 -march=i386 \ -mtune=generic Compared to the first one, all the others have one more instruction in the function. E.g. between s1 and s3 there is: @@ -44,17 +41,18 @@ foo: addl %edi, %ebx imull $7471, %ecx, %edi leal 32768(%ebx,%edi), %ebx - imull $-15119, %eax, %edi sarl $16, %ebx movb %bl, -3(%ebp) movl %edx, %ebx sall $15, %ebx - subl %edx, %ebx + movl %ebx, %edi + imull $-15119, %eax, %ebx + subl %edx, %edi + imull $13282, %edx, %edx addl %edi, %ebx imull $-17648, %ecx, %edi - imull $13282, %edx, %edx - leal 32768(%ebx,%edi), %ebx imull $19485, %ecx, %ecx + leal 32768(%ebx,%edi), %ebx sarl $16, %ebx movb %bl, -2(%ebp) movl %eax, %ebx s1 to s4 has more changes, but also one more instruction.
Taking a closer look.
GCC 6.1 has been released.
GCC 6.2 is being released, adjusting target milestone.
GCC 6.3 is being released, adjusting target milestone.
GCC 6.4 is being released, adjusting target milestone.
GCC 6 branch is being closed
From my reading, it looks like we do worse now than in previous releases. Things look OK going into IRA. The IRA allocations are different, but I haven't analyzed in any detail why and if one is inherently better than the other. LRA inserts more reloads/copies on the trunk than we did way back in r228097.
The GCC 7 branch is being closed, re-targeting to GCC 8.4.
GCC 8.4.0 has been released, adjusting target milestone.
GCC 8 branch is being closed.
GCC 9.4 is being released, retargeting bugs to GCC 9.5.
GCC 9 branch is being closed
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
GCC 10 branch is being closed.
GCC 11 branch is being closed.