Matthew Fortune <matthew.fort...@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
