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:
>> I think instead we should have a configuration switch that allows a
>> particular -mfp option to be inserted alongside -mabi=32 if no explicit
>> -mfp is given.  This is how most --with options work.  Maybe --with-fp-
>> 32={32|64|xx}?  Specific triples could set a default value if they like.
>> E.g. the MTI, SDE and mipsisa* ones would probably want to default to --
>> with-32-fp=xx.  Triples aimed at MIPS IV and below would stay as they
>> are.  (MIPS IV is sometimes used with -mabi=32.)
>> 
>> --with-fp-32 isn't the greatest name but is at least consistent with
>> --with-arch-32 and -mabi=32.  Maybe --with-fp-32=64 is so weird that
>> breaking consistency is better though.
>
> Tying the use of fpxx by default to a configure time setting is OK with
> me. When enabled it would still have to follow the rules as defined in
> the design in that it can only apply to architectures that can support
> the variant.

Right.  It's really equivalent to putting the -mfp on every command line
that doesn't have one.

> Currently that means everything but mips1.

Yeah, using -mips1 on a --with-{o}32-fp=xx toolchain would be an error.

> I'm not sure this is the same as tying an ABI to an architecture as
> both fp32 and fpxx are O32 and link compatible. Perhaps the configure
> switch would be --with-o32-fp={32|64|xx}. This shows it is just an O32
> related setting.

What I meant is that -march= and -mips shouldn't imply a different
-mfp setting.  The -mfp setting should be self-contained and it should
be an error if the architecture isn't compatible.

We might be in violent agreement here :-)  Like I say, I was just a
bit worried by the earlier -mips32r2 thing because there was a time
when a -mips option really could imply things like -mabi, -mgp and -mfp.

--with-o32-fp would be OK with me.  I'm just worried about the ABI
being spelt differently from -mabi=, but there's probably no perfect
alternative.

>> > Currently newlib's implementation is assembly code with no
>> > .gnu_attributes. Under the rules above this would start to be
>> > implicitly tagged as gnu_attribute 4,1 (fp32). Any thoughts on how we
>> > transition this to fpxx and still have the modules buildable with old
>> > tools as well? I'm not sure if it will be acceptable to say that it
>> > has to be rewritten in C.
>> 
>> If it's assembled as -mfpxx then it'll be implicitly tagged with the new
>> .gnu_attribute rather than 4,1.  If it's not assembled as -mfpxx then
>> 4,1 would be the right choice.
>
> So this would be dependent on the build system ensuring -mfpxx is passed
> as appropriate if the toolchain supports it. There is some risk in this
> too if the existing code (which I know is not fpxx safe) gets built with
> a new toolchain then it will be tagged as fpxx. I wonder if this tells
> us that command line options cannot safely set the FP ABI away from the
> default. Instead only the .module and .gnu_attribute can set it as only
> the source code can know what FP mode it was written for. The change to
> your 4 points above would be that the module level setting is not
> impacted by the command line -mfp options.

I don't think that's necessary.  For one thing, there's always the
problem with unannotated asm code that the command-line options might
be wrong.  There's often not much we can do about that.  E.g. we have to
assume that code assembled as -mabi=n32 really is n32 code and not n64
code (and produce a 32-bit rather than 64-bit ELF).  There's no way of
hedging our bets in that case: we have to pick an ABI.

For another, leaving the attribute as the default 0 makes the object
compatible with everything, so a file assembled with the wrong -mfpyy
could still be linked with other -mfpyy files.  I don't think it gives
us anything extra.

The interaction between .module and command-line options should be the
same for all .module/.set options.

Thanks,
Richard


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