Issue 123278
Summary Missed optimization between `range` parameter metadata and `assume`s
Labels new issue
Assignees
Reporter scottmcm
    Now that `range` parameter metadata exists (🎉) I'm trying to remove some of our `assume`s that `rustc` outputs which should no longer be necessary.

That works for almost all of our tests in https://github.com/rust-lang/rust/blob/master/tests/codegen/transmute-optimized.rs , but one.

We end up, after optimizations, still getting 
```rust
define noundef range(i8 1, 4) i8 @ordering_transmute_onetwothree(i8 noundef returned range(i8 -1, 2) %x) unnamed_addr #2 {
start:
  %0 = icmp ne i8 %x, 0
  tail call void @llvm.assume(i1 %0)
  %1 = icmp ult i8 %x, 4
  tail call void @llvm.assume(i1 %1)
  ret i8 %x
}
```

That input range is `[-1, 2)` and those assumes are a range `[1, 4)`, so it ought to simplify to just `ret i8 1`, but it doesn't.

Alive2 proof that it would be legal: <https://alive2.llvm.org/ce/z/GucQsJ> -- and legal even without the `range` on the return value.

Maybe this is somehow related to the `x uge 1` being turned into `x ne 0`, and thus it not noticing there's a range?  Or maybe it's something about the wrap-around?

SEO: rust transmute range bounds

---

As an aside, I'd love to emit these as `range` [assume operand bundles](https://llvm.org/docs/LangRef.html#assume-operand-bundles) instead of `icmp`s, but AFAICT those don't exist yet, so I'm stuck with the `icmp`s for now 🙁 

_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to