5a64bc207e
These assert that there are no "useless" assertzext/assertsext nodes (that assert a wider width than a following trunc), but I don't think there is anything preventing such nodes from reaching this code. I don't think the assertion is relevant for correctness of this transform either -- if such an assert is present, then the other one will always be to a smaller width, and we'll pick that one. The assertion dates back to D37017. Fixes https://github.com/llvm/llvm-project/issues/55846. Differential Revision: https://reviews.llvm.org/D126952
27 lines
791 B
LLVM
27 lines
791 B
LLVM
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
; RUN: llc -mtriple=x86_64-unknown-linux-gnu < %s | FileCheck %s
|
|
|
|
; After legalization, this could be: "i8 truncate (i64 AssertZext X, Type: i9)"
|
|
; The AssertZext does not add information, so it should be eliminated,
|
|
; but that must not trigger a compile-time assert.
|
|
|
|
define void @test(i64* %p) {
|
|
; CHECK-LABEL: test:
|
|
; CHECK: # %bb.0:
|
|
; CHECK-NEXT: movl $256, %eax # imm = 0x100
|
|
; CHECK-NEXT: movq %rax, (%rdi)
|
|
; CHECK-NEXT: retq
|
|
%sel = select i1 true, i64 256, i64 0
|
|
br label %bb2
|
|
|
|
bb2:
|
|
store i64 %sel, i64* %p, align 4
|
|
%p.bc = bitcast i64* %p to <2 x i1>*
|
|
%load = load <2 x i1>, <2 x i1>* %p.bc, align 1
|
|
br label %bb3
|
|
|
|
bb3:
|
|
%use = add <2 x i1> %load, zeroinitializer
|
|
ret void
|
|
}
|