> Matthew Fortune <matthew.fort...@imgtec.com> writes: > >> > Sorry, forgot about that. In that case maybe program headers would > >> > be best, like you say. I.e. we could use a combination of GNU > >> > attributes and a new program header, with the program header > >> > hopefully being more general than for just this case. I suppose > >> > this comes back to the thread from binutils@ last year about how to > >> > manage the dwindling number of free flags: > >> > > >> > https://www.sourceware.org/ml/binutils/2013-09/msg00039.html > >> > to https://www.sourceware.org/ml/binutils/2013-09/msg00099.html > >> > > > > > There are a couple of issues to resolve in order to use gnu attributes > > to record FP requirements at the module level. As it currently stands > > gnu attributes are controlled via the .gnu_attribute directive and > > these are emitted explicitly by the compiler. I think it is important > > that a more meaningful directive is available but it will need to > > interact nicely with the .gnu_attribute as well. > > > > The first problem is that there will be new ways to influence whether > > a gnu attribute is emitted or not. i.e. the command line options > > -mfp32, -mfpxx, -mfp64 will infer the relevant attribute > > Tag_GNU_MIPS_ABI_FP and if the .module directive is present then that > > would override it. Will there be any problems with a new ways to > generate a gnu attribute? > > I think we should just give an error if any .gnu_attributes are > inconsistent with the module-level setting (whether that comes from > .module or command-line flags).
I would need to account for the -msoft-float and -msingle-float command line options to calculate module-level setting in order to do this, which is fine. There is however no way to infer the no-float ABI from command line options as it is not passed through from the GCC driver. This would mean the no-float ABI would always conflict with the module level setting. I suspect the only answer is to make an exception and allow a .gnu_attribute 4,0 to take precedence over a command line option (but not a .module option). This seems a little convoluted in the end. The only other alternative is to just allow the .module fp=... options to act as human readable aliases for the .gnu_attribute options and take whatever comes last. > > The second problem is that in order to support relaxing a mode > > requirement then any up-front directive/command line option that sets > > a specific fp32/fp64 requirement needs to be updated to fpxx. With gnu > > attributes this would mean updating an existing Tag_GNU_MIPS_ABI_FP > > setting to be modeless. > > Not sure what you mean here, sorry. At the end of a unit we will know whether an FP32 or FP64 ABI can be relaxed to FPXX. This will happen if no floating point code has been emitted that uses odd numbered registers. All I was checking is that it is going to be acceptable to alter the FP ABI attribute even if it was set using the .gnu_attribute directive. I know I 'can' do it in the code as I have it working already just checking that it is OK. I suppose this case is going to be quite rare (hand written assembly code that includes a .gnu_attribute 4,1 which is mode safe) but I'd like to catch as many cases as possible and relax the ABI. Regards, Matthew
