This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: ppc64 floating point usage [was Re: PPC64 Compiler bug !!]
- From: linas at austin dot ibm dot com
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Fri, 13 Jun 2003 16:02:25 -0500
- Subject: Re: ppc64 floating point usage [was Re: PPC64 Compiler bug !!]
- References: <jakub@redhat.com> <200306132009.QAA28822@makai.watson.ibm.com>
On Fri, Jun 13, 2003 at 04:09:06PM -0400, David Edelsohn wrote:
> >>>>> Jakub Jelinek writes:
>
> Jakub> I guess best would be if GCC could dynamically switch the reg alloc orders
> Jakub> based on whether FPRs will be used anyway or whether current function is
> Jakub> pure integer code.
Why would this be best?
> Yes. The difficulty is determining whether a function is pure
> integer code.
I just finished reading the October archives on this issue. One of
the notes hinted at a flag in some struct that indicated if a function
used float. Not clear if the flag was hypothetical or real.
Barring further discussion of eh, setjump/longjump & variadic funcs,
it seems to me such a flag could be easily computed early on (although
it might slow down compilation a tad to do so).
> Even more, one does not want to simply change the alloc
> order but mark FPRs as fixed for pure integer code, which is what
> -msoft-float does.
Bird in hand vs. two in the bush. We have Alan Modra's patch now, we
don't have an acceptable -mno-implicit-float patch.
There is concern that Alan's patch will negatively impact performance
of fp code. Is there a way to unambiguously resolve this issue, or
at least resolve it to everyones satisfaction?
How would one do this? Visually inspect generated fp code? Run
benchmarks? Which benchmarks?
--linas