Richard Sandiford <rdsandif...@googlemail.com> writes: > 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.
Yes that is what I understood. > >> 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. As it stands I wasn't planning on supporting .module arch= I was just going to add .module fp= and leave it at that. The only thing I need to give assembly code writers absolute control over is the overall FP mode of the module. I don't currently see any real need to increase the control a user has over architecture level. If we had .module arch= then having it just set the arch ignorant of FP mode seems fine, checking for erroneous combinations would be difficult due to some chicken and egg scenarios. Do you think I need to add .module arch= if I add .module fp= or can I take the easy option? Regards, Matthew