PPC64 Compiler bug !!

[linas at austin.ibm.com]

Hi Alan,

On Fri, Jun 13, 2003 at 07:17:30AM +0930, Alan Modra wrote:
> Various people have tried to implement patches that prevent floating
> point regs being used for moves.  For examples, see
>
> http://gcc.gnu.org/ml/gcc/2003-06/msg00902.html
> http://gcc.gnu.org/ml/gcc/2002-10/msg00707.html
>
> Yes, I could also try to fix gcc to not use float regs for integer
> moves, but my attempt would also likely be blocked by the current
> rs6000 maintainers.  The trouble is that to prevent this problem
> re-occurring in kernel code, you'd need to have the options on
> *by default*, and this will have some impact on user code that could use
> extra registers.
>
> --
> Alan Modra
> IBM OzLabs - Linux Technology Centre

Yikes!  I had no idea this was a hot issue.  Let me think aloud here
for a little bit, and see who agrees with what.

1) The use of fp for DImode move is an interesting optimization if
   either:
   a) one has run out of regular DImode GPR's. But this was not
      the case for the simple test case I sent in: I was compiling for
      a 64-bit target, there were plenty of unused GPR's.
   b) there is some neato cpu-implementation detail that makes the
      cpu instruction issue or instruction pipeline go faster by using
      fp regs for copies.  I have no idea, I'd be surprised.

2) Last I looked at gcc guts, there was a way of indicating a preference
   for which machine description would get used.  I don't know if that
   mechanism is flexible enough.  Naively, I would think that the
   right thing to do would be to implement a DImode would use GPR's
   till GPR's got exhausted, and then start using FPR's.  I'll bet
   that this would make 99% of all FPR moves disappear.

3) For Linux kernel hackers, there seems to be an acceptable work-around
   with the -msoft-float flag.  I'm willing to accept this flag.

   Note, however, that this optimization seems to have a real, measurable
   economic effect: there has been plenty of time and salary $$ spent
   on this issue: In my area alone, the original report of the
   kernel crash has floated up & down the management chain, and has
   impacted the critical timeline for new hardware development.

   Given the history of the mailing list postings, it seems like
   I'm not the only one who has been caught off-guard by this.

4) At other times/other eras/other compilers, this sure smells like
   an -O3 optimization not an -O2 optimization.   I've got nothing
   against optimizations, but the fpr-move is generated even when
   optimization is turned off.

   Its a surprise. Surprises cause chaos and economic loss.  If this
   insn was generated when I said -O3, I would have said to myself,
   'wow, what a wild and freaky and interesting optimization, the
   guy/gal who came up with this was a genius!'

   Instead, its hard to keep myself from thinking 'wow, wild and
   freaky! Whoever did this was a moron!  I wasted a day cleaning
   up after this turd!'

5) There are some user-land issues having to do with Linux
   context-switching when an app uses fpr's.  With the gcc-3.2.0
   ppc64 compiler, I get the impression that *every* ppc64 app
   is an FP app.  I don't know if that's the case for gcc-3.2.2
   or if this happens when compiling for the 32-bit target.

   Because of 1a) and 2), it seems to me that there is a performance
   loss, because the binary didn't actually run faster (because it
   wasn't tight on GPR's), but it did run slower cause of the
   kernel context switch.   So at least with 3.2.0, a 64-bit
   app would see a net performance loss. (albeit slight).

Based on the above logic,  I want to conclude that the right thing
to do is to make ppc64 use GPR's not FPR's for the default DImode
move, and make it so that the DI move uses FPR's when -O3 is specified.

Assuming that someone provided a patch to do this, would the rs6000
maintainers turn it down?

--linas


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