https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64342
--- Comment #7 from vries at gcc dot gnu.org --- (In reply to Igor Zamyatin from comment #1) > avx512f-kandnw-1.c and funcspec-5.c seem to be non-PIC related issues. I > asked Kirill to look at them. > I cannot reproduce the funcspec-5.c failure with r216154, so that failure was unrelated (and fixed in r220079). I can reproduce that avx512f-kandnw-1.c started failing with r216154, in -fpic -m32 mode only. Given comment 6, it could be a benign case of different code generation, split triggered, output scan failure. > Others are not stability but more performance issues - generated code is > less effective than it should be - in one case for some reasons compiler > uses callee-saved ebx in PIC mode instead of edx in non-PIC mode and in xmm > case compiler uses stack in PIC mode instead of xmm register in non-PIC mode > > I see that differencies between PIC and non-PIC modes start on reload pass > so I'd like Vlad to look at these cases I can reproduce that fuse-caller-save.c started failing with r216154, in -fpic -m32 mode only. The code is less optimal with r216154: ... foo: .LFB1: .cfi_startproc - movl %eax, %edx + pushl %ebx + .cfi_def_cfa_offset 8 + .cfi_offset 3, -8 + movl %eax, %ebx call bar - addl %edx, %eax + addl %ebx, %eax + popl %ebx + .cfi_restore 3 + .cfi_def_cfa_offset 4 ret .cfi_endproc ... Before r216154, bx is considered clobbered in bar by collect_fn_hard_reg_set_usage, because it's part of fixed_reg_set. With r216154, bx is no longer part of fixed_reg_set, and bx becomes available for register allocation in foo. I'm not familiar with the pic register code, so I don't know whether this is safe. Register allocation seems to progress similarly, up until this message in reload, with seems to be directly related to the r216154 patch: ... Spill r86 after risky transformations Reassigning non-reload pseudos Assign 3 to r86 (freq=3000) ... So, it seems the r216154 patch introduces a performance degradation for -m32 -fpic for the fuse-caller-save example.