[PATCH] D136529: [DAG] canCreateUndefOrPoison - add support for SRA/SRL shift opcode (WIP)

[Craig Topper via Phabricator via llvm-commits]

craig.topper added inline comments.


================
Comment at: llvm/test/CodeGen/RISCV/rv64zbb.ll:255
 ; RV64I-NEXT:    .cfi_offset ra, -8
-; RV64I-NEXT:    srliw a1, a0, 1
+; RV64I-NEXT:    srli a1, a0, 1
 ; RV64I-NEXT:    or a0, a0, a1
----------------
RKSimon wrote:
> @craig.topper I'm familiar with the riscv shift code, but moving the freeze out of the way has changed:
> ```
>   t2: i64,ch = CopyFromReg t0, Register:i64 %0
>       t127: i64 = and t2, Constant:i64<4294967295>
>     t30: i64 = srl t127, Constant:i64<1>
> ```
> to
> ```
>     t2: i64,ch = CopyFromReg t0, Register:i64 %0
>   t4: i64 = AssertZext t2, ValueType:ch:i31
>     t32: i64 = srl t4, Constant:i64<1>
>   t33: i64 = or t4, t32
> ```
srliw is a 32-bit shift right in a 64-bit register. It's equivalent to (srl (and X, 0xffffffff), C).

Looks like SimplifyDemandedBits is not figuring out that bit 31 is zero due to the AssertZExt.

So we end up with (srl (and X, 0x7fffffff), C) instead.

We don't have an and with immediate for that constant so we use a shift left followed by shift right for the combination.

I tried adding a computeKnownBits call during isel to try to recover the mask, but it looks like it hit the depth limit before it got to the AssertZExt.

I think all the ANDs before every SRL after type legalization allowed us to propagate more information before some of them they got removed. Some weird visitation order I guess.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136529