RE: EGCS-19981101 EXPERIMENTAL TEST IRIX6.4 WITH WORKING G++

[tprince at cat dot e-mail dot com]

          -Reply


From: Jeffrey A Law <law@upchuck.cygnus.com>


  In message
<4.19981104.16.15.23.137205@cat.e-mail.com>you write:
  >
  > Aside from breaking the x86 version, the new optimizations
gain
  > a little bit on R10K in many situations, but show a big loss in
  > some branching situations (Livermore Kernels 16).
  > Dr. Timothy C. Prince
Interesting.  Any chance you could analyze the problem with mips
and the
livermore kernels?  I'm a little suprised that they had that kind of
effect.

jeff


I compared the results from last week's prerelease and
experimental snapshots.  While the experimental 2.92.18 equals
or exceeds the performance of the pre-release 2.91.58 in every
section of the test, recent snapshots had much better
performance in this one test, where they nearly equalled the
performance of the MipsPro 7.2 compiler.

The attached shar file shows this segment of source code, as I
have re-processed it to change the archaic arithmetic IF's and
GOTO's to g77 style.  I suspect the major difference between the
fast 2.92.16 version and the slow 2.92.18 is in the recognition of
the pointers to COMMON blocks (almost) as loop invariants.
These pointers have the g77 internal names spaces_ and
spacer_.  The named integer variables are stored in spaces,
and the named single precision floating point variables are
stored in spacer.

The loop body head label is .L206 in both cases, and it will be
seen that those 2 pointers are loaded to register ahead of the
loop in the fast case.  In the slow case, it seems that a big delay
is introduced by the additional level of indirection which has to be
resolved before the first branch condition in the loop can be
evaluated.  The values in the zone() array are set in a totally
inscrutable way and I have no idea whether the branching
pattern responds to "prediction."

In both cases, there is a refetch of spaces_ in the middle of the
loop, apparently associated only with the incrementing of the
counter k3, but this appears not to be on the critical path.  Neither
the fast nor the slow code is holding k3 as a register variable,
but this doesn't seem to be so important.  The fast code places
this pointer redundantly in the same register where it is for the
other calculations, while the slow code is re-using a register
which is being used for other pointer calculations, but one would
think that the hardware shadow register mapping would take
care of this.

No doubt this is more than you bargained for, on a case of
doubtful practical significance.  It's even likely that copying those
static counters to local variables for the duration of the loop, the
kind of tactic which gnu compilers used to depend on, would
make the difference.
Dr. Timothy C. Prince
Consulting Engineer
Solar Turbines, a Caterpillar Company
alternate e-mail: tprince@computer.org

           To:                                              INTERNET - IBMMAIL
                                                            N4248388 - IBMMAIL