Re: too much GCSE in ia64

[Brad Lucier <lucier at math dot purdue dot edu>]

Re:

> Actually, even plain wrong code was generated in another case (note that
> -fno-sched-spec-dangerous did not help) active: in presence of cases like
> 
>      *sp++ = selfCache->object->data[2]
> 
> GCC wanted to hoist the computation of &selfCache->object->data[2] too to
> all the case blocks too.  This is disastrous if selfCache happens not to
> be valid.

Please submit a bug report; I'm sure it will be of interest to GCC developers.

Re:

> My interpreter has many bytecodes like "push local variable #1", "push
> local variable #2", and so on, which are open-coded and implemented like
> 
>      *sp++ = tempCache[2];
> 
> inside a huge switch statement.  Now, GCSE moved all the address
> computations to *every* case block, generating some 60 completely useless
> adds for every bytecode: that is 10 wasted clock cycles per bytecode on
> the Itanium (instead of 6 clock cycles that GNU Smalltalk manages to
> obtain with -fno-gcse).  This is even more useless considering that there
> is a lot of room for scheduling the effective address generation in the
> basic block containing the statement above!

My guess is that you are using computed gotos (goto *x) in your interpreter.
Current GCSE does not handle code with critical edges very well; it considers
dead all variables at the beginning of blocks that are the target of a
computed goto, thus leading to reloading of many expressions at the beginning
of such blocks.  (Previously, GCSE could generate incorrect code in such
a situation, so this is an improvement, I suppose.)  If each bytecode has
its own labeled block of code to implement it, then each bytecode's block
will have all this expression reloading at the beginning of it.

Michael Matz has told me that he is implementing an idea of Oliver Ruething
on how to do Lazy Code Motion (the transformation behind GCSE in gcc)
in the presence of critical edges.  Until then, I suggest disabling gcse
on codes like yours.

Brad Lucier