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