Enable EBX for x86 in 32bits PIC code

Jeff Law law@redhat.com
Tue Sep 23 15:59:00 GMT 2014


On 09/23/14 08:23, Uros Bizjak wrote:
> On Tue, Sep 23, 2014 at 3:54 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>
>> Here is a patch which combines results of my and Vladimir's work on EBX enabling.
>>
>> It works OK for SPEC2000 and SPEC2006 on -Ofast + LTO.  It passes bootstrap but there are few new failures in make check.
>>
>> gcc.target/i386/pic-1.c fails because it doesn't expect we can use EBX in 32bit PIC mode
>> gcc.target/i386/pr55458.c fails due to the same reason
>> gcc.target/i386/pr23098.c fails because compiler fails to use float constant as an immediate and loads it from GOT instead
>>
>> Do we have the final decision about having a sompiler flag to control enabling of pseudo PIC register?  I think we should have a possibility to use fixed EBX at least until we make sure pseudo PIC doesn't harm debug info generation. If we have such option then gcc.target/i386/pic-1.c and gcc.target/i386/pr55458.c should be modified, otherwise these tests should be removed.
>
> I think having this flag would be dangerous. In effect, this flag
> would be a hidden -ffixed-bx, with unwanted consequences on asm code
> that handles ebx. As an example, please see config/i386/cpuid.h - ATM,
> we handle ebx in a special way when __PIC__ is defined. With your
> patch, we will have to handle it in a special way when new flag is in
> effect, which is impossible, unless another compiler-generated define
> is emitted.
>
> So, I vote to change PIC reg to a pseudo unconditionally and adjust
> testsuite for all (expected) fall-out.
Agreed.  Continuing to support both modes just seems like a maintenance 
nightmare and asking for problems at some point.  If there's performance 
regressions, we just tackle them :-)

I suspect any performance regressions we find are going to point us at 
issues in IRA/LRA that we would want to look at anyway.

jeff



More information about the Gcc-patches mailing list