[PATCH] D63590: [PowerPC] Sign extend the select instr operands if it is any_extend

[Qing Shan Zhang via Phabricator via llvm-commits]

steven.zhang marked 2 inline comments as done.
steven.zhang added inline comments.


================
Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:12325
       else
-        Ops[C+i] = DAG.getAnyExtOrTrunc(Ops[C+i], dl, N->getValueType(0));
+        llvm_unreachable("Unexpected opcode!");
     }
----------------
hfinkel wrote:
> This seems like we're working around a problem elsewhere. Why does forcing any_extend to become a sign_extend produce better code than just producing an any_extend?
For any_extend, it is handled as zero extend if it is constant. For example, 
```
t1: i8 = select t0, Constant:i8<-1>, Constant:i8<0>
t2: i64 = any_extend t1
```
It  will be combined as follows, for now:
```
t3: i64 = select t0, Constant:i64<255>, Constant:i64<0>
```
And the literal "255" is just a normal constant, therefore, the combine to inreg rule won't apply. This is what we expected:
```
t3: i64 = select t0, Constant:i64<-1>, Constant:i64<0>
```
So that, the combine to inreg rule would apply and it is combined as:
t4: i64 = sign_extend_inreg t3

Doing zero extend will hurt some opportunities, while sign extend indeed helps. And we haven't seen the downside yet.


================
Comment at: llvm/test/CodeGen/PowerPC/bool-math.ll:9
-; CHECK-NEXT:    ori 3, 3, 65508
-; CHECK-NEXT:    oris 3, 3, 65535
 ; CHECK-NEXT:    blr
----------------
hfinkel wrote:
> Is this a regression - it looks like we're going from two instructions to three?
No, both are three instructions. 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63590/new/

https://reviews.llvm.org/D63590