PPC64 Compiler bug !!

[linas at austin.ibm.com]

On Fri, Jun 13, 2003 at 12:50:17AM -0400, David Edelsohn wrote:
> >>>>> linas  writes:
>
> linas> Assuming that someone provided a patch to do this, would the rs6000
> linas> maintainers turn it down?
>
> 	Yes, any such patch will be rejected.
>
> 	Customers, especially in the embedded space, do not want
> "discourage use of FPRs for DImode",

Maybe I've forgotten how gcc works, but isn't DImode an "integer only
function"?  I thought DF was for double-floats.?  I haven't looked at
gcc source for years, excuse my confusion.

> they want "promise to not use any
> FPRs in an integer-only function".

I have a very simple integer-only function, which I compile w/o
any optimization at all, and it uses FPR's.  Lets look at the code again:

void spin_lock(int *lock);

long
linas_lock(int dev)
{
     long flags =0;

     spin_lock(&dev);
     return flags;
}

When compiled for a 64-bit target, there should be gobs of free 64-bit
regs; I have a hard time understanding why the use of an FPR is desired
or advantageous in any way in this func.

> GCC cannot accomplish that safely in
> the target-specific portion of the compiler.

What do you mean by 'safely'? Surely -msoft-float is "safe" or is that
not true?

During one of the intermediate stages of processing, one must surely
be able to scan the function and realize that it was integer-only.
At this point, if -O3 is not set, one could internally turn on -msoft-float,
and continue onwards.  Surely, this would be a safe and simple way to
gaurentee the desired result.

Its possible such a patch would also hit target-independent code.

--linas

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/