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