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

[Jeffrey A Law <law@cygnus.com>]

  In message < 404f573f.35a864cf@aol.com >you write:
  > Kernel 9 performance at vector length 101 drops from 58 to 52 Mflops with
  > gcse.  At vector length 15, it is 57 Mflops either way.  This is definitely
  > abnormal, for performance to drop with increasing vector length, and, to me,
  > this would indicate an increase in cache miss rate.
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.

The dcache effects could possibly occur due to additional register
pressure causing more spills and access into stack slots.

One experiment you might consider trying is to run the older classic
gcse pass instead of the pre based gcse pass.  It doesn't tend to
expand code as much and finds fewer redundancies (and thus needs fewer
regs with cross-block lifetimes).


Look for this code in gcse.c:

      if (optimize_size)
        changed |= one_classic_gcse_pass (f, pass + 1);
      else
        changed |= one_pre_gcse_pass (f, pass + 1);

Change "optimize_size" to "1" to try running the classic gcse pass
instead of the pre based gcse pass.


The majority of the cases where I've seen pre lose in the past have
been register pressure issues.  Addressing these concerns is one of
the primary motivations behind the "lazy code motion" based version
of pre/gcse that Cygnus will donate later this year.

Other cases have been secondary effects related to register lifetimes
and the like.  For example, a register created by gcse may be set in
multiple places, which inhibits certain optimizations -- the old
code would compute the same value in multiple locations into multiple
regs (usually each being set only once).  That kind of stuff.


jeff