This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, "macro at codesourcery dot com" <macro at codesourcery dot com>, "Joseph Myers (joseph at codesourcery dot com)" <joseph at codesourcery dot com>, "Moore, Catherine (Catherine_Moore at mentor dot com)" <Catherine_Moore at mentor dot com>
- Date: Mon, 3 Mar 2014 23:17:28 +0000
- Subject: RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023534AAE6E at LEMAIL01 dot le dot imgtec dot org> <87mwhhg9e5 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534AC1F0 at LEMAIL01 dot le dot imgtec dot org> <878ut0fj45 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534AD16E at LEMAIL01 dot le dot imgtec dot org> <87ppmbdobm dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534AEB92 at LEMAIL01 dot le dot imgtec dot org>
> > 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?
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.
I don't think any other port does this kind of thing in binutils but that doesn't mean we can't I guess.
Regards,
Matthew