(really Fortran patches)

Jeffrey A Law law@cygnus.com
Thu Oct 23 00:47:00 GMT 1997


This gets more interesting by the minute.

Like many modern cpus, the PA has a counter that increments once per
machine cycle -- and the counter is visible to the user :-)

So, I got off my lazy butt and started timing stuff -- basically noting
the time for any particular loop takes for one of the 100 iterations
in tomcatv.

I ran across a pretty simple loop, which ran slower with the USE patch,
so I started fooling around.

Fixing the giv combination problem by hand made things a little
better, but relative to the total slowdown, it was in the noise --
even after pulling another invariant out of the outer loop
(it's a double nested loop).

The slowdown turned out to be a bad schedule.  After hand fixing
the schedule the version with the USE patch ran faster than the
one without the USE patch.

The loop is dominated by memory and FP latency (no suprise with
tomcatv).  With the USE patch the scheduler did not move some of
the memory instructions as aggressively as it used to.

I'm wondering if the givs created by the USE patch are confusing
the alias code into thinking some particular memory addresses
conflict, when in fact they don't.  Before you ask, no nothing
needed to move past an autoincrement memory reference :-)

I'll look at this further as soon as I can get another block of
free time.

I don't know if bad schedules will account for all the slowdown,
but one can always hope!

jeff



More information about the Gcc mailing list