Matthew Fortune <matthew.fort...@imgtec.com> writes: >> 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.
-mno-float the GCC option doesn't really select a different ABI. It does leave the FP attribute as being the default 0/dont-care, but that's just like it would be when compiling most hand-written assembly code, including code written before -mno-float or .gnu_attribute was invented. > 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. I don't think we should ever override an explicit .gnu_attribute. The most we can do is report a contradiction. >> > 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. Yeah, I don't think we should do any relaxation like that. If a specific attribute value is chosen we should honour it even if it doesn't seem necessary. If -mfp32, -mfp64, .module fp=32 or .module fp=64 is used we should honour it even if -mfpxx or .module fp=xx seems OK. Thanks, Richard