Re: [SH4] splits after reload

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

> I have prepared a target dependent patch for SH4, attached with
> the mail. When any DFmode Load/Store insn in split (in flow2), the
> address arithmetic insn is recorded in an array. A marker
> (UNSPECV_DF_SPLIT) is put in the insn stream on first split.
> Then, in peep2 pass, these address arithmetic insns are recombined
> with other ADD incsns in the same basic block if possible. The care
> has been taken of deleted insns and blocks during flow2 pass. Following
> is the overview of changes made:
> 
>   config/sh/sh.c  (fix_df_splits) : New function
>                   (try_recombine) : New function
>                   (split_array, split_index) : New variables defined
>   config/sh/sh.md : New define_peephole2
>                   : Modifications in define_split for DFmode load/store

Where is the "df_split" pattern?
Is a define_peephole allowed to modify or delete instructions that it
did not match?  I haven't found anything to this effect in md.texi.
If there isn't some clause there that I overlooked, we should probably
add one before we require this to work.
When a pattern is unnamed, we generally use the previous name with +n
appended, where n is a number describing how far back the named pattern is.
(E.g. if there are four splitter patterns after a named pattern extendpqiti2,
the third splitter is called extendpqiti2+3.)
The constant 512 as a hard upper limit on the number of handled instructions
seems rather arbitrary.  I think you should use a varray instead, growing
it as needed. (e.g. you can start with 512 and double every time you run out
of space).
(const_int 0) is the NOP pattern.  This will generate an actual NOP
instruction, and can't be optimized away unless it is unreachable.
Instead, you can try to use DONE to emit nothing (I haven't checked if
this is currently supported, but if not, it shouldn't be hard to fix that),
or emit a nop-op move.

I get the impression that fix_df_splits is called possibly multiple times,
and will fail if free (0) fails.

I also think that it is rather fragile to store information about the
interesting instruction at split time, and the UNSPECV_DF_SPLIT might get
in the way of valid optimizations.

You are also calling delete_insn in try_recombine; this is asking for
trouble if the deleted instruction happens to precede the instruction
that is matched by the peephole2.

Considering that you habe O(n^2) behaviour anyway - you scan the insn
stream in the current extended basic block for every increment - I think
you might as well just match an increment with a peephole2, and search
forward for a matching increment.