Combine Pass Behavior

Combine Pass Behavior

[Oleg Endo]

Hi all,

I'm currently trying to find the best way to solve PR 49263 and I've ran
into some questions regarding the combine pass.

Summary of the story:

The SH machine description has a pattern that is supposed to generate
the "tst #imm, r0" instruction as a combination of an and and a
comparison, where #imm is an unsigned byte (0...255):

(define_insn ""
  [(set (reg:SI T_REG)
	(eq:SI (and:SI (match_operand:SI 0 "arith_reg_operand" "z,r")
		       (match_operand:SI 1 "logical_operand" "K08,r"))
	       (const_int 0)))]
  "TARGET_SH1"
  "tst	%1,%0"
  [(set_attr "type" "mt_group")])

However, the combine pass does not find this pattern for certain bit
patterns, because it tries to combine the two insns..

(insn 10 7 11 2 (set (reg:SI 170)
        (and:SI (reg/v:SI 164 [ x ])
            (const_int 4 [0x4]))) {*andsi3_compact}
     (expr_list:REG_DEAD (reg/v:SI 164 [ x ])
        (nil)))

(insn 11 10 17 2 (set (reg:SI 147 t)
        (eq:SI (reg:SI 170)
            (const_int 0 [0]))) {cmpeqsi_t}
     (expr_list:REG_DEAD (reg:SI 170)
        (nil)))


into something like this....

(set (reg:SI 147 t)
    (eq:SI (zero_extract:SI (reg:SI 4 r4 [ x ])
            (const_int 2 [0x2])
            (const_int 0 [0]))
        (const_int 0 [0])))

or .. 

(set (reg:SI 147 t)
    (zero_extract:SI (xor:SI (reg:SI 4 r4 [ x ])
            (const_int 4 [0x4]))
        (const_int 1 [0x1])
        (const_int 2 [0x2])))

or .. 

(set (reg:SI 168)
    (and:SI (not:SI (reg:SI 4 r4 [ x ]))
        (const_int 1 [0x1])))

.. and a couple of other variants.


The actual problem (or maybe my misunderstanding) is that it
combines the two original insns, then does some substitutions and tries
to match the combined and transformed insn against those defined in the
machine description.  If it can't find anything there it reverts
everything and proceeds with the next insn pair.  It never tries out the
straight forward option in the first place (which is not to transform
the combination). 

As a quick hack for myself I've added a second combine pass (ran after
the original combine pass) where the function 

  make_compound_operation (rtx x, enum rtx_code in_code) 

simply returns x instead of expanding it into a zero_extract.  This
fixed most of the issues at hand, but doesn't sound quite right.

Is the scenario above intended behavior of the combine pass or an
accident?  Or maybe even something else wrong in the machine description
that makes it behave like that?  At least it sounds very related to PR
30829.

Thanks,
Oleg

Re: Combine Pass Behavior

[Eric Botcazou]

> The actual problem (or maybe my misunderstanding) is that it
> combines the two original insns, then does some substitutions and tries
> to match the combined and transformed insn against those defined in the
> machine description.  If it can't find anything there it reverts
> everything and proceeds with the next insn pair.  It never tries out the
> straight forward option in the first place (which is not to transform
> the combination).

The combiner pass does some form of canonicalization to better combine, see 
expand_compound_operation and make_compound_operation.

> Is the scenario above intended behavior of the combine pass or an
> accident?  Or maybe even something else wrong in the machine description
> that makes it behave like that?

See how the i386 back-end copes with this for its "test" instruction.

-- 
Eric Botcazou