Re: FOUND! PA2.0 float performance problem

[Jeffrey A Law <law at hurl dot cygnus dot com>]

  In message <199902231916.LAA01800@kankakee.wrs.com>you write:
  > 
  > Change
  > 
  > #define REG_ALLOC_ORDER \
[ ... ]
Yea.  That's basically what I had in mind short term.

Really modeling this problem is hard -- it requires quite a bit of
knowledge about scheduling issues inside the register allocators.

[ ... ]
  > and retest, and let us know how it goes.  I suspect the compiler will
  > always get better code with the exception of possibly much worse
  > prologues and epilogues.  Anyway, I suspect this isn't the right fix,
  > or at best is only part of it, but for you, it may be better than
  > wating for the right fix.  At least part of the right fix is to expose
  > the conflicts to the scheduler.
I don't think the prologues will get that much worse, and for the cases
where the prologue do get worse, the performance of the code is likely
dominated by the floating point operations themsevles

One way to mitigate that problem is by having a switch (-mschedule=8000) which
rearranges REG_ALLOC_ORDER only when optimizing for a PA8000 class machine
(which is the only class of machines with the false dependency and PA8000
machines are likely to be more tolerant of the prologue/epilogue
inefficiencies.


jeff