Skip to content

enums with disjoint ranges should emit more precise llvm.range metadata #133822

Open
@Kmeakin

Description

@Kmeakin

I tried this code:
https://godbolt.org/z/4KKGvWs8d

#[derive(Copy, Clone)]
pub enum Foo {
    Foo1 = 1,
    Foo2 = 2,
    Foo4 = 4,
    Foo8 = 8,
}

#[no_mangle]
pub fn load(foo: &Foo) -> u32 {
    *foo as u32
}

I expected to see this happen: The metadata attatched to the load should specify that the loaded value is either 1, 2, 4 or 8:

define noundef range(i32 1, 8) i32 @load(ptr noalias nocapture noundef readonly align 1 dereferenceable(1) %foo) unnamed_addr #0 {
  %0 = load i8, ptr %foo, align 1, !range !2, !noundef !3
  %_0 = zext nneg i8 %0 to i32
  ret i32 %_0
}

!2 = !{
  i8 1, i8 3, ; 1 or 2
  i8 4, i8 5, ; 4
  i8 8, i8 9, ; 8
 }

Instead, this happened: the range metadata gives a still correct, but less accurate range of [1,9):

define noundef range(i32 1, 8) i32 @load(ptr noalias nocapture noundef readonly align 1 dereferenceable(1) %foo) unnamed_addr #0 {
  %0 = load i8, ptr %foo, align 1, !range !2, !noundef !3
  %_0 = zext nneg i8 %0 to i32
  ret i32 %_0
}

!2 = !{i8 1, i8 9}

Similarly, the range attribute for the return value of load (and the range attribute for a value of type Foo if it is passed by value) is also less precise than it could be. But it appears from reading the LLVM LangRef that range attributes can only specify a single range, rather than a union of disjoint ranges like llvm.range metadata can.

Meta

rustc --version --verbose:

rustc 1.85.0-nightly (5e1440ae5 2024-12-01)
binary: rustc
commit-hash: 5e1440ae514d98ddfcbf1607acb64d41e07ef616
commit-date: 2024-12-01
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.4
Backtrace

<backtrace>

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.A-codegenArea: Code generationC-optimizationCategory: An issue highlighting optimization opportunities or PRs implementing suchI-slowIssue: Problems and improvements with respect to performance of generated code.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions