RE: splits after reload

["Rakesh Kumar - Software, Noida" <rakeshku at noida dot hcltech dot com>]

> 
> > My idea is to recombine the instructions,
> > if possible, as and when splitting takes place. As in this 
> case, at the
> > time of DFmode store insn, the splitter could have looked 
> for the previous
> > use/definition of r1, hence removing two address arithmetic 
> instructions.
> 
> That seems risky.  splitting can happen in multiple places, and an
> instruction that is split is not necessarily emitted.  combine for
> instance will try splits, and then sometimes throw the result away.

 I agree, but I was thinking about postreload splits. Is there any
probability of throwing away the splitted instructions after reload?
 
> Try defining a peephole2 pattern to handle this.  You need to split it
> into nothing, but there should be a way to make that work.

 I thought about peephole2. But it seems making the optimization too
local. A peephole has the limitation on the window size. As the window
size increases, one is forced to write more and more peepholes. Besides,
there is a hoard of operations that could be efficiently recombined,
for instance - ADD, SUB, OR, XOR, etc. The number of peepholes increase
proportionately.  With implementation in try_split, window could be
as big as basic block.

The splits after reload would be occuring on other targets also.
I was just wondering if such problems crop up for any other target.
If yes, it would be much beneficial to apply the optimization at
generic level, rather than any machine specific optimization like 
peephole2. IMHO, it would help the scheduling pass to work more
efficiently.

Thanks and Regards,
Rakesh Kumar