Re: [PATCH] SH: New define_split sh.md

[Joern Rennecke <joern dot rennecke at superh dot com>]

> Actually, that introduces one more issue.
> HAVE_peephole2 is undefined for SH at the moment.
> So, introducing it increases a compile time overhead
> as an extra pass will run on the insn-chain.
> I think I need to measure that.

I wouldn't worry about this.  In the long run, I expect that we will have
several peephole2 patterns for the SH.
If peephole2 is actually slowing things down significantly, we should
look into improving the implementation.

> And we also need to consider:
> 1. Although we avoid a possible stall by looking at the 
>    surrounding insns, we have the literal pool. 
>    The case, where we need to insert a branch around the literal pool,
>    will make  decision  of *not* synthesizing the literal earlier,
>    look bad. 

This only matters if we need a completely new literal pool on behalf of this
constant.  I would expect this to be rare, as literals tend to be clustered.

> 2. The peephole is a local picture.

Well, at least it is less local than looking at a single instruction in
isolation.

> 3. The benchmarking that I did suggests that splitting 
>    is a win, even if, surrounding insns are not considered.
>    However, I cannot claim that is always the case.

Where a code transformation appears to have potential drawbacks of comparable
magnitude as potential gains, benchmarking can only give useful guidance if
it is done with a large and diverse body of code that is representative of
the various uses that the processor is being used for.  Unfortunately,
the effort to do this is prohibitive most of the times :-(