[all-commits] [llvm/llvm-project] 2e77ae: [RISCV] Give up on correct undef semantics in mul ...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2e77aea22f11d0acf13b32fec0df81351a1e236a
      https://github.com/llvm/llvm-project/commit/2e77aea22f11d0acf13b32fec0df81351a1e236a
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2024-04-25 (Thu, 25 Apr 2024)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVISelLowering.cpp
    M llvm/test/CodeGen/RISCV/rv64zba.ll

  Log Message:
  -----------
  [RISCV] Give up on correct undef semantics in mul strength reduction (#90097)

This is a change I really don't like posting, but I think we're out of
other options.  As can be seen in the test differences, we have cases
where adding the freeze inhibits real optimizations.
    
Given no other target handles the undef semantics correctly here, I
think the practical answer is that we shouldn't either.  Yuck.
    
As examples, consider:
* combineMulSpecial in X86.
* performMulCombine in AArch64
    
The only other real option I see here is to move all of the strength
reduction code out of ISEL.  We could do this either via tablegen rules,
or as an MI pass, but other than shifting the point where we ignore
undef
semantics, I don't this is meaningfully different.
    
Note that the particular tests included here would be fixed if we added
SHA/SHL to canCreateUndefOrPoison. However, a) that's already been tried
twice and exposes its own set of regressions, and b) these are simply
examples.  You can create many alternate examples.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications