This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: split a parallel expression and then combine


On Wed, Oct 29, 2014 at 02:57:28PM -0700, Cherry Vanc wrote:
> I want to replace the following :
> 
> op1
> ...
> op2 ( depends on op1 )
> ...
> op3  ( depends on op1 )
> 
> 
> with
> 
> ...
> op2'
> ...
> op3'

This transform is often called "uncse".  It is not something combine can
do well.  It is much more natural to do it in fwprop.

The transform is also not always a win (it lenghtens the lifetime of the
inputs to op1).  For machines with enough registers it usually is a win
though.

> I noticed in the combine dump that the compiler was appropriately looking for
> 
> Failed to match this instruction:
> (parallel [
>         (set (reg:SI 222)
>             (op2:SI ( op1 (reg 219) (reg 109)))
>         (set (reg:DI 202)
>             (op1:DI (reg 219) (reg 109)))
>     ])
> 
> To achieve above-mentioned task, I did the following ( in the same
> order as below in the md file ) :
> 
> 1. define_insn_and_split to split the above parallel expression into
> two separate insns - op2 (op1) and op1
> 2. define_insn op2 (op1) = op2'
> 3. define_insn op3 (op1) = op3'
> 
> Because of the define_insn_and_split, the above parallel expression is
> correctly split into two separate insns - op2 (op1) and op1 (and
> subsequently op2' is picked up for op2(op1)).

It is only split after combine.  If you want the op3 thing to work, you'll
need to define a pattern that is a parallel of op1, op2', op3' as well; and
another one that is a parallel of op2', op3'.  This doesn't scale.

> But the combine pass
> does NOT then attempt to combine op3 and op1.

It currently does not allow any of the earlier insns in a combination to be
a parallel, yes (except for some special cases).

> I tried the define_insn_and_split with and without specifying "
> reload_completed" (Sorry but even after few weeks of playing with the
> backends, I am not completely clear on the relevance of
> "reload_completed" in this context)

A define_insn_and_split with reload_completed in the split condition will
not do the split until after reload.  This is usually used for splitters
that want to know what registers (or memory) are assigned to the operands.

Without reload_completed, the split is done after combine, before register
allocation.  This is usually better (if you can get away with it).

> Can some give some insight into how can this be achieved ? What am I
> doing wrong ?

Don't try to do this in combine.  It is not going to work (or work well).


Segher


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]