Re: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589

[Segher Boessenkool <segher at kernel dot crashing dot org>]

On Thu, Nov 29, 2018 at 05:20:03PM +0100, Jakub Jelinek wrote:
> On Thu, Nov 29, 2018 at 05:10:33PM +0100, Uros Bizjak wrote:
> > Maybe a combine splitter can be used here? Please see documentation
> > from paragraph 17.16 onward:
> > 
> > --quote--
> >  The insn combiner phase also splits putative insns.  If three insns are
> > merged into one insn with a complex expression that cannot be matched by
> > some 'define_insn' pattern, the combiner phase attempts to split the
> > complex pattern into two insns that are recognized.  Usually it can
> > break the complex pattern into two patterns by splitting out some
> > subexpression.  However, in some other cases, such as performing an
> > addition of a large constant in two insns on a RISC machine, the way to
> > split the addition into two insns is machine-dependent.
> 
> Maybe, but not sure how the define_split would look like.
> We essentially want to match any RTL whatsoever that has some MEM in it
> and if the MEM address is of certain kind, move some part of it.
> 
> combine.c has also find_split_point function which does the right thing
> in the foo case, just doesn't for the bar case.

Yes, that is to find where to split an insn into two (with a new intermediate
register).  It uses heuristics and finds at most *one* place to try.

Maybe the heuristics can be improved here?

Something like change_zero_ext can be used to try a different form for the
same instruction, but trying something like that while producing more than
one insn is probably hard to do (and not very useful).


Segher