[patch] h8300.c: Improve shifts.

[Kazu Hirata]

Hi Jeff,

> I'm actually not sure this is an improvement -- what kinds of 
> tests have you
> done on the performance?  What about correctness (you do know 
> you can run the
> gcc testsuite using the H8 simulator, right?)

I did not do massive tests for this.  To be honest, I did not know I can
actually use the simulator.  Looking at manuals, I am hoping to find
something for site.exp or DEJAGNU variable, but could you point me to the
right direction?  I am having trouble finding the last bit of information.
Now I've realized that the patch may be unsafe because I did not tighten the
predicate for rotates to refuse a shift by variable.

> Yes, but it allowed optimizations elsewhere like cse, 
> combine, gcse that
> are not possible with your patch because the RTL it generates 
> is far more
> complex than pretending the target as a shift-by-variable-count insn.

I was expecting combine to do something like:

(n << m) << 2

to

n << (m + 2)

but this did not happen.  I haven't looked into this, though.

> I would think you'd want to fix the shifting patterns to not have the 
> alternative for shifts by a variable amount.  I believe that 
> in turn will
> allow you to rewrite the shift patterns without the clobber 
> of a scratch.

I thought about that, but some constants still require a scratch (and a
loop), so I can't really delete it.  If I did a loop-at-rtl-time even for a
shift by a constant, then that would kill all the benefits of combine.

I'll try to improve this one as well as testing and some reasoning/analysis
to show what kind of optimizations on shifts are possible given various
constraints imposed by the H8.

Thanks,

Kazu Hirata