Zero-extended i1 value becomes 255 at -O2 on x86_64

[topolarity]

; ModuleID = 'test'
source_filename = "test"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define external ccc void @"_start"() unnamed_addr {
Entry:
  %0 = alloca i1
  call fastcc void @foo(i1* sret(i1) %0)
  %1 = load i1, i1* %0
  %2 = zext i1 %1 to i64
  call i64 asm sideeffect "syscall", "={rax},{rax},{rdi},~{rcx},~{r11},~{memory},~{dirflag},~{fpsr},~{flags}"(i64 231, i64 %2)
  unreachable
}

define internal fastcc void @foo(i1* nocapture nonnull writeonly sret(i1) %0) unnamed_addr noinline {
Entry: 
  %1 = alloca i1
  store i1 true, i1* %1
  %2 = bitcast i1* %0 to i8*
  %3 = bitcast i1* %1 to i8*
  %4 = load i8, i8* %3
  store i8 %4, i8* %2
  ret void
}

With LLVM 14.0.5, this program gives a correct result at -O0, but at -O1 the zero-extended i1 value is 255:

$ opt-14 test.ll -o test.bc -filetype=obj -O0
$ llc-14 ./test.bc -O0 -o ./test.o -filetype=obj
$ ld.lld -o test ./test.o && ./test
$ echo $?
1
$ opt-14 test.ll -o test.bc -filetype=obj -O1
$ llc-14 ./test.bc -O1 -o ./test.o -filetype=obj
$ ld.lld -o test ./test.o && ./test
$ echo $?
255

Does not reproduce with LLVM 13.0.1:

$ opt-13 test.ll -o test.bc -filetype=obj -O0
$ llc-13 ./test.bc -O0 -o ./test.o -filetype=obj
$ ld.lld -o test ./test.o && ./test
$ echo $?
1
$ opt-13 test.ll -o test.bc -filetype=obj -O1
$ llc-13 ./test.bc -O1 -o ./test.o -filetype=obj
$ ld.lld -o test ./test.o && ./test
$ echo $?
1

[llvmbot]

@llvm/issue-subscribers-backend-x86

[llvmbot]

@llvm/issue-subscribers-bug

[topolarity]

Looks like this is already fixed on trunk: https://godbolt.org/z/Ehbxz7471

It would be good to know what change includes the fix, if possible

[nikic]

This was probably fixed by 930a687.

[topolarity]

Indeed, applying that fix locally resolves this bug for me. Thank you!

[CGQAQ]

This was probably fixed by 930a687.

930a687#diff-06e121216084579cd62acf88c315555529dc0dbfbeba81787c70ab7e606bdb21L507-R508

HOW????
the DL.getTypeSizeInBits and DL.getTypeStoreSize should be 8 anyway, thus TypeSize::isKnownLE(LoadSize, StoreSize) in the next line is true, why this change will fix the issue, I don't understand

EDIT 1
is it the other way around? after this change the TypeSize::isKnownLE(LoadSize, StoreSize) will be false ( LoadSize is 8, StoreSize is 1), and the branch is not hit, the function returns nullptr?

EDIT 2
I think I got it, the issue hit this case, which is not valid, and trigger the UB