Re: 19980707 built on win95/i686-pc-cygwin32

[N8TM at aol dot com]

In a message dated 7/12/98 12:44:04 AM Pacific Daylight Time,
law@hurl.cygnus.com writes:
>icache or dcache?
> Either could be adversely effected I suppose.
>  
>  The partial redundancy elimination based version of gcse tends to trade
>  code size for code speed.  So if your code is icache sensitive it could
>  be a lose.

I certainly don't know all there is to know about cache, but I believe that
icache and dcache are separate at level 1, not at level 2.  The performance
loss is occurring when both code size and data size increase, but not unless
both occur, and not in Linux.  So it looks to me like a level 2 cache miss
issue, with Linux apparently allowing a longer life for level 2 cache data.
Most of these Livermore loops are small enough that they ought to to stick in
level 1 cache, with the aid of the p2align scheme.  Kernels 9 and 16 are
bigger than average, but Kernel 11, which Linux also improves on, is (or ought
to be) small even with unrolling.

<One experiment you might consider trying is to run the older classic
<gcse pass instead of the pre based gcse pass.

I'll do that.

<The majority of the cases where I've seen pre lose in the past have
<been register pressure issues.

That certainly must make it tough to make a compiler which optimizes both on
Intel and on architectures with 4 times as many registers available.  I would
think that an "optimization" which loses on account of register pressure in
Livermore Kernels is not one I would want active in general.  I think there is
a correlation here, too, with the relative performance of gcc-2.8.1/g77-0.5.23
and egcs.  Egcs tends to achieve top performance on cases which don't need
many registers but fall down on ones which want to use more registers than are
available.