[PATCH] D29489: Optimize SETCC + VSEL of incompatible or illegal types

[Jonas Paulsson via Phabricator via llvm-commits]

jonpa added a comment.

> You land in WidenVecRes_SELECT if the VSELECT result type is illegal, and PromoteIntOp_SELECT if the VSELECT result type is legal.  I'm surprised PromoteIntOp_SELECT doesn't do the right thing without your special-case code, though; could you trace through and figure out what's happening?  What goes wrong after PromoteTargetBoolean promotes the SETCC to an appropriate type?

In PromoteIntOp_SELECT() (trunk), PromoteTargetBoolean() promotes the boolean result vector by creating a new SIGN_EXTEND node for it.

This new SIGN_EXTEND is then legalized immediately after, and the SETCC result vector again produces a call to PromoteIntegerOperand(). The SETCC has however been handled before, and GetPromotedInteger() returns here a SIGN_EXTEND_VECTOR_INREG of the previously handled SETCC. The SETCC here has a legal (widened) integer vector type. PromoteIntOp_SIGN_EXTEND then adds two more extensions: ANY_EXTEND and SIGN_EXTEND_INREG of this. This results in:

  Type-legalized selection DAG: BB#0 'fun:'
  SelectionDAG has 18 nodes:
    t0: ch = EntryToken
              t2: v8i16,ch = CopyFromReg t0, Register:v8i16 %vreg0
              t4: v8i16,ch = CopyFromReg t0, Register:v8i16 %vreg1
            t19: v8i16 = setcc t2, t4, seteq:ch
          t22: v4i32 = sign_extend_vector_inreg t19
        t25: v4i32 = sign_extend_inreg t22, ValueType:ch:v4i1
        t6: v4i32,ch = CopyFromReg t0, Register:v4i32 %vreg2
        t8: v4i32,ch = CopyFromReg t0, Register:v4i32 %vreg3
      t14: v4i32 = vselect t25, t6, t8
    t16: ch,glue = CopyToReg t0, Register:v4i32 %V24, t14
    t17: ch = SystemZISD::RET_FLAG t16, Register:v4i32 %V24, t16:1

Here then is the extra SIGN_EXTEND_INREG (t25) that I tried to explicitly eliminate in my first version of the patch, which results in two unnecessary shifts on SystemZ.

As far as I can see now this is the only reason for handling in PromoteIntOp_SELECT(). Could perhaps this extra SIGN_EXTEND_INREG be avoided in the first place instead somehow?


https://reviews.llvm.org/D29489