Skip to content

Missed optimization between range parameter metadata and assumes #123278

Closed as not planned
@scottmcm

Description

@scottmcm

Now that range parameter metadata exists (🎉) I'm trying to remove some of our assumes that rustc outputs which should no longer be necessary (rust-lang/rust#135610).

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

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 instead of icmps, but AFAICT those don't exist yet, so I'm stuck with the icmps for now 🙁

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions