This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
> 



-- 




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]