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.