This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: rearranging REG_ALLOC_ORDER in gcc/config/rs6000/rs6000.h
- From: <gp at qnx dot com>
- To: "David Edelsohn" <dje at watson dot ibm dot com>, <gp at qnx dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Tue, 10 Jun 2003 19:51:46 -0000
- Subject: Re: rearranging REG_ALLOC_ORDER in gcc/config/rs6000/rs6000.h
Is there no middle ground? It seems to me that if this sort of thing (not
necessarily my approach) can improve performance on targets that use fpu
emulation, it is better to have an optional incomplete solution that helps
than nothing at all.
Perhaps if I read some of those earlier threads, I would find answers to
these kinds of questions. Do you have any URLs? Or maybe a timeframe so I
can search the archives?
Thanks.
GP
David Edelsohn <dje@watson.ibm.com> said:
> >>>>> GP writes:
>
> GP> We have found that re-arranging the REG_ALLOC_ORDER in rs6000.h so that
all
> GP> the FP registers come after the integer registers greatly reduces the
> GP> tendency of the compiler to generate code that moves 8-byte quantites
through
> GP> the FP registers. This is good for code that may run both on targets
both
> GP> with and without an FPU, minimizing the performance hit of using an fpu-
> GP> emulator.
>
> Thanks for contributing another patch to avoid most uses of FPRs
> in moves of integer quantities. Previous discussions about this issue
> seem to come to the conclusion that a "-mno-fp-moves" flag must ensure
> that no FPRs are used in integer code, not merely reduce the tendency of
> the compiler to use FPRs. Safely implementing the former is non-trivial
> and probably cannot be done in the target-specific portion of the
> compiler.
>
> Thanks, David
>
--