Missed optimization when using `llvm.assume`, although scalar-evolution can use it to figure out the range.

[AAAA-I]

Missed optimization: store i1 %0, ptr @a, align 1 --> store i1 true, ptr @a, align 1

@a = external global i1
define i1 @src(ptr %G) {
BB:
  %L = load i1, ptr %G, align 1
  %0 = xor i1 %L, true
  store i1 %0, ptr @a, align 1
  call void @llvm.assume(i1 %0)
  ret i1 %0
}

clang-trunk -O3 generates:

define noundef i1 @src(ptr readonly captures(none) %G) local_unnamed_addr #0 {
  %L = load i1, ptr %G, align 1
  %0 = xor i1 %L, true
  store i1 %0, ptr @a, align 1
  tail call void @llvm.assume(i1 %0)
  ret i1 true
}

We found that scalar-evolution looked like it could do some analysis with llvm.assume (it found that the value of %L was false), but the optimization was still missed:

Printing analysis 'Scalar Evolution Analysis' for function 'src':
Classifying expressions for: @src
  %L = load i1, ptr %G, align 1
  -->  %L U: [0,-1) S: [0,-1)

Godbolt: https://godbolt.org/z/bd9fEGe18
Alive2 proof: https://alive2.llvm.org/ce/z/AYhVHx
The reduced IR is derived from https://github.com/torvalds/linux/blob/f4d2ef48250ad057e4f00087967b5ff366da9f39/mm/page_alloc.c#L2201. We added assume above to restrict the variable's value and debug.

[nikic]

The reduced IR is derived from https://github.com/torvalds/linux/blob/master/mm/page_alloc.c

Can you please be a bit more precise about where in that file this pattern occurs?

[AAAA-I]

Can you please be a bit more precise about where in that file this pattern occurs?

Thank you for your reply. We have edited the original report. The source program is derived from: https://github.com/torvalds/linux/blob/f4d2ef48250ad057e4f00087967b5ff366da9f39/mm/page_alloc.c#L2201. We added assume above to restrict the variable's value and debug.

Other than that, the following case of further reduction is a very common read-store operation in the real world?
https://godbolt.org/z/4MT8oP3fE

@a = external global i1
define i1 @src(ptr %G) {
  %L = load i1, ptr %G, align 1
  store i1 %L, ptr @a, align 1
  call void @llvm.assume(i1 %L)
  ret i1 0
}

We report the original case above because during our investigation, we found that value range analysis worked for the above case, so we guessed that fixing that could improve even more optimizations using value range analysis (If this guess is wrong, thank you for correcting it). If the further reduced code is a more valuable case, we are willing to replace it with the original case above.

[ftyghome]

I found an interesting variant: when you perform simple arithmetic operations (like add) on %L, the optimization seems to apply correctly to the values derived from these operations:

@a = external global i32
@b = external global i32
declare void @llvm.assume(i1)

define i32 @src(ptr %G) {
BB:
  %L = load i32, ptr %G, align 4
  
  ; Case1: store the value after a simple operation
  %H = add i32 %L, 1
  store i32 %H, ptr @a, align 4
  ; Case2: store directly
  store i32 %L, ptr @b, align 4
  
  %cmp = icmp eq i32 %L, 10
  call void @llvm.assume(i1 %cmp)
  
  ret i32 %L
}

clang-trunk -O3 generates:

define noundef i32 @src(ptr readonly captures(none) %G) local_unnamed_addr #1 {
BB:
  %L = load i32, ptr %G, align 4
  store i32 11, ptr @a, align 4
  store i32 %L, ptr @b, align 4
  %cmp = icmp eq i32 %L, 10
  tail call void @llvm.assume(i1 %cmp)
  ret i32 10
}

I am currently working on this :)

[ftyghome]

After further investigation, I believe the root cause may be in the IPSCCP Pass, specifically related to the insertion positions of predicate and ssa_copy instructions in the PredicateInfoBuilder::materializeStack function. I'm working on a potential fix and will update with more information once I have a solution.