This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking


Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
>> > With these defaults, the closest supported ABI is used for each
>> > architecture based on the --with-o32-fp build option. The only one I
>> > really care about is the middle one as it makes full use of the O32
>> > FPXX ABI without a user needing to account for arch restrictions.
>> 
>> Note that --with-* options just insert a canned -mfoo=bar option under
>> certain conditions, with those conditions being the same regardless of
>> "bar".
>> So --with-o32-fp=32 should insert -mfp32 (and nothing else), --with-o32-
>> fp=64 should insert -mfp64, etc.
>> 
>> The rules should therefore be the same for both -mfp and --with-o32-fp.
>> Should:
>> 
>>   mips-*-gcc -march=mips1 -mfpxx
>> 
>> generate -mfp32 code too?  It seems counter-intuitive to me.
>> 
>> I suppose it depends on what you want -mfpxx to mean.  Do you want it to
>> mean "use the new ABI that is link-compatible with both -mfp32 and -
>> mfp64"
>> or do you want it to mean "I don't care what the FR setting is; pick
>> whatever seems best but be as flexible as possible"?  I'd assumed the
>> former, in which case using it with an architecture that doesn't support
>> it should be an error.
>
> In the end I do just want fpxx to mean use the new ABI that is
> link-compatible. I think I have managed to confuse this discussion by
> not understanding/separating vendor specific specs from generic option
> handling as you explain later in your email. I only really wish to allow
> a vendor specific config to infer a suitable default fp option from
> -march (like -mabi=32 for 32-bit arch and -mabi=n32 for 64-bit arch).

Well, for avoidance of doubt, --with has priority over the vendor-specific
choices, so really this comes down to what happens when no -mfp and
--with-o32-fp options are used.

>> If you want to go for tha latter meaning then I think we should be
>> careful to distinguish it from cases where we really are talking about
>> the new ABI variant.  E.g. an ELF file has to commit to one of the three
>> modes: you shouldn't have to look at the ELF's architecture setting in
>> order to interpret the FP setting correctly.  And IMO the assembly code
>> needs to commit to a specific mode too.  What do you think should happen
>> for:
>> 
>>       .module fp=xx
>>       .module arch=mips_n
>> 
>> Should the output be FR=X or FR=1?
>
> Well, even defining fpxx as simply being another abi variant there are
> some issues. The current .set arch= options set fp32 for 32-bit
> architectures and fp64 for 64-bit architectures which means we do have
> to come up with some definition of how fpxx interacts with this. My
> current implementation is that, for .set arch, the fp option is only
> changed if the existing setting is incompatible with the new arch. So
> carrying that logic to .module means that in the case above then the
> output would be FPXX. Other examples would then be:
>
> .module fp=xx
> .module arch=mips_n
> <FPXX>
> .module fp=32
> .module arch=mips_n
> <FP64>
>
> .module fp=xx
> .module arch=mips2
> <FPXX>
> .module fp=64
> .module arch=mips2
> <FP32> (existing behaviour for .set)
>
> .module fp=xx
> .module arch=mips1
> <FP32>
> .module fp=64
> .module arch=mips1 
> <FP32> (existing behaviour for .set)
>
> This is weird though for the same reasons as you point out. You have to
> know the arch to know what happens to the FP mode. If we just continued
> with 32-bit arch setting fp=32 and 64-bit setting fp=64 then we have a
> problem with something like mips_n where fp=32 would be invalid. I
> really don't know what is best here!

The ".set mips" handling of gp and fp is really there for local changes
to the architecture in a .set push/pop or .set mipsN/mips0.  (And IMO we
the way we do it is a bit of a misfeature, but we have to keep it that
way for compatibility.)

I don't think it should apply to .module though.  Ideally .module should
work in the same way as passing the associated command-line option.

Thanks,
Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]