[MIPS] Avoiding FP operations/register usage

[MIPS] Avoiding FP operations/register usage

[Matthew Fortune]

Hi Richard,

I've been trying to determine for some time whether the MIPS backend has successfully guaranteed that even when compiling with hard-float enabled there is no floating point code emitted unless you use floating point types.

My most recent reason for looking at this is because I am starting to understand/look at mips ld.so from glibc and it appears to make such an assumption. I.e. I cannot see it using any specific options to prevent the use of floating point but the path into the dynamic linker for resolving symbols only preserves integer argument registers and ignores floating point. I have to therefore assume that the MIPS backend manages to avoid what I thought was a common problem of using floating point registers as integer scratch in extreme circumstances.

An another example of where this issue is relevant is the MIPS linux kernel which explicitly compiles for soft-float, whether this is out of caution or necessity I do not know but I'm interested to figure it out.

Any insight into this would be welcome. If there is no such guarantee (which is what I have assumed thus far) then I will go ahead fix anything that relies on avoiding floating point code.

Regards,
Matthew 

Re: [MIPS] Avoiding FP operations/register usage

[Joseph S. Myers]

On Fri, 7 Feb 2014, Matthew Fortune wrote:

> My most recent reason for looking at this is because I am starting to 
> understand/look at mips ld.so from glibc and it appears to make such an 
> assumption. I.e. I cannot see it using any specific options to prevent 
> the use of floating point but the path into the dynamic linker for 
> resolving symbols only preserves integer argument registers and ignores 
> floating point. I have to therefore assume that the MIPS backend manages 
> to avoid what I thought was a common problem of using floating point 
> registers as integer scratch in extreme circumstances.

Even if you avoid use of floating point (via -ffixed-* options - check 
carefully that those are actually effective, as for some targets there are 
or have been initialization order issues for registers that are only 
conditionally available, that may make such options ineffective - not 
-msoft-float, as that would mark the objects ABI-incompatible), you'd 
still need to save and restore call-clobbered registers used for argument 
passing, because IFUNC resolvers, audit modules and user implementations 
of malloc might clobber them.  Thus, I think ld.so needs to save and 
restore those registers (and so there isn't much point making it avoid 
floating point).  See 
<https://sourceware.org/ml/libc-alpha/2014-01/msg00673.html>.

-- 
Joseph S. Myers
joseph@codesourcery.com

RE: [MIPS] Avoiding FP operations/register usage

[Matthew Fortune]

> > My most recent reason for looking at this is because I am starting to
> > understand/look at mips ld.so from glibc and it appears to make such
> > an assumption. I.e. I cannot see it using any specific options to
> > prevent the use of floating point but the path into the dynamic linker
> > for resolving symbols only preserves integer argument registers and
> > ignores floating point. I have to therefore assume that the MIPS
> > backend manages to avoid what I thought was a common problem of using
> > floating point registers as integer scratch in extreme circumstances.
> 
> Even if you avoid use of floating point (via -ffixed-* options - check carefully
> that those are actually effective, as for some targets there are or have been
> initialization order issues for registers that are only conditionally available,
> that may make such options ineffective - not -msoft-float, as that would
> mark the objects ABI-incompatible), you'd still need to save and restore call-
> clobbered registers used for argument passing, because IFUNC resolvers,
> audit modules and user implementations of malloc might clobber them.

This is where I was going next with this but I didn't know if it was appropriate to go into such things on the GCC list.

> Thus, I think ld.so needs to save and restore those registers (and so there
> isn't much point making it avoid floating point).  See
> <https://sourceware.org/ml/libc-alpha/2014-01/msg00673.html>.

Thanks for this and I agree. I've read some of the threads on this topic but not these. I have also realised I've stumbled my way into something that will also affect/be affected by how we define the ABI extension for MSA. If we define an ABI extension that uses MSA registers for arguments then these would also need saving around dynamic loader entry points.

I'm still interested in how successfully the MIPS backend is managing to avoid floating point but I am also convinced there are bugs in ld.so entry points for MIPS.

Matthew

Re: [MIPS] Avoiding FP operations/register usage

[Richard Sandiford]

Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> I'm still interested in how successfully the MIPS backend is managing to
> avoid floating point but I am also convinced there are bugs in ld.so
> entry points for MIPS.

It uses the standard mechanism to avoid it, which is marking uses of
FP registers for integer moves, loads and stores with "*".  This tells
the register allocator to ignore those alternatives.  AFAIK it is
effective and I think any cases where it doesn't work would be fair
bug reports.

It becomes a lot more difficult to define with things like the Loongson
extensions though, since some of those are also useful as scalar integer
operations.  And of course the same goes for MSA.

Thanks,
Richard

RE: [MIPS] Avoiding FP operations/register usage

[Matthew Fortune]

> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> > I'm still interested in how successfully the MIPS backend is managing
> > to avoid floating point but I am also convinced there are bugs in
> > ld.so entry points for MIPS.
> 
> It uses the standard mechanism to avoid it, which is marking uses of FP
> registers for integer moves, loads and stores with "*".  This tells the register
> allocator to ignore those alternatives.  AFAIK it is effective and I think any
> cases where it doesn't work would be fair bug reports.

I understand that '*' has no effect on whether reload/LRA will use the alternative though so I take that to mean they could still allocate FP regs as part of an integer move?

> It becomes a lot more difficult to define with things like the Loongson
> extensions though, since some of those are also useful as scalar integer
> operations.  And of course the same goes for MSA.

Indeed.

Avoiding FP registers 99.9% of time is fine for performance, it's the potential 0.1% I'm concerned about for correctness. I'm tending towards accounting for potential FPU usage even from integer only source just to be safe. I don't want to ever be the one debugging something like ld.so in the face of this kind of bug.

I'll move the discussion to glibc regarding ld.so.

Regards,
Matthew

Re: [MIPS] Avoiding FP operations/register usage

[Richard Sandiford]

Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
>> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
>> > I'm still interested in how successfully the MIPS backend is managing
>> > to avoid floating point but I am also convinced there are bugs in
>> > ld.so entry points for MIPS.
>> 
>> It uses the standard mechanism to avoid it, which is marking uses of FP
>> registers for integer moves, loads and stores with "*".  This tells
>> the register
>> allocator to ignore those alternatives.  AFAIK it is effective and I think any
>> cases where it doesn't work would be fair bug reports.
>
> I understand that '*' has no effect on whether reload/LRA will use the
> alternative though so I take that to mean they could still allocate FP
> regs as part of an integer move?

No, they shouldn't.  Admittedly the mechanism for reload is a bit indirect:
the GPR alternatives have priority and there is no GPR-and-FPR register
class that could be used to sum up separate "d" and "*f" alternatives.
It should be effective though.  There too I think any case where it
didn't work would be a bug.

ISTR LRA handles reloads by generating reload pseudos.  IMO it should
never do that for a '*' class, since that's tantamount to allocating
a pseudo to that class.  I haven't checked whether LRA enforces that
or not though.

Thanks,
Richard