Richard Sandiford <rdsandif...@googlemail.com> writes: > 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.
Are you're OK with automatically selecting fpxx if no -mfp option, no .module and no .gnu_attribute exists? Such code would currently end up as FP ABI Any even if FP code was present, I don't suppose anything would get worse if this existing behaviour simply continued though. For this to be sufficient we would be making the assumption that there is almost no hand written code that has a .gnu_attribute directive nor build system that explicitly uses the -mfp32 option. I think this will certainly hold true for assembly modules that have no FP code in them but presumably anyone who has hand-written FP code will have used the .gnu_attribute. We will lose the ability for such modules to quietly transition to fpxx but I have no data to say how many of such modules exist or may exist in the future. I still need to check if there are any hand written FP modules in the standard libraries. I am concerned about this aspect but I expect it could be revisited if it turns out to be overly cautious or restrictive. Thinking specifically about potential projects that may want to have hand written fpxx code with new tools and still build with older tools... The only solution I can see is that it would be possible with some configure time detection of whether the .module directive is supported and then some pre-processing to emit a suitable directive (.gnu_attribute 4,1 for old tools and .module fpxx for new). Regards, Matthew
