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

Reply via email to