-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
possible intresting issue with physical pointers #1133
Comments
I wonder if this issue is related? I can't verify the lowering of this one either: define void @f() {
%1 = alloca i32, align 4
call void @test1(ptr %1)
ret void
}
declare void @test1(ptr) the lifted code I end up with is: define void @f() local_unnamed_addr {
arm_tv_entry:
%stack = tail call align 16 dereferenceable(1280) ptr @myalloc(i64 1280, i64 16)
%0 = getelementptr inbounds i8, ptr %stack, i64 1024
%1 = ptrtoint ptr %0 to i64
%2 = getelementptr inbounds i8, ptr %stack, i64 1008
store i64 0, ptr %2, align 16
%a5_1 = add i64 %1, -4
%3 = inttoptr i64 %a5_1 to ptr
tail call void @test1(ptr nonnull %3)
tail call void @myfree(ptr nonnull %stack)
ret void
}
; Function Attrs: mustprogress willreturn allockind("alloc") allocsize(0)
declare nonnull ptr @myalloc(i64, i64 allocalign) local_unnamed_addr #0
; Function Attrs: mustprogress willreturn allockind("free")
declare void @myfree(ptr allocptr) local_unnamed_addr #1
declare void @test1(ptr) local_unnamed_addr
attributes #0 = { mustprogress willreturn allockind("alloc") allocsize(0) "alloc-family"="arm-tv-alloc" }
attributes #1 = { mustprogress willreturn allockind("free") "alloc-family"="arm-tv-alloc" } |
ok, sorry to pile on the examples, but here's one more, and this one is really stopping me from verifying interesting programs. the src/tgt pair below does not verify in assembly mode. however, it does verify if I remove the ptr2int/int2ptr round trip, replace it with a GEP, and invoke alive-tv without assembly mode, but disabling poison and undef inputs. src is: define <4 x i32> @f(<4 x i32> %a) {
%c = shufflevector <4 x i32> %a, <4 x i32> <i32 5, i32 6, i32 7, i32 8>, <4 x i32> <i32 0, i32 1, i32 6, i32 7>
ret <4 x i32> %c
} tgt is: %0 = type { i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8 }
@.LCPI0_0 = constant %0 { i8 0, i8 0, i8 0, i8 0, i8 0, i8 0, i8 0, i8 0, i8 7, i8 0, i8 0, i8 0, i8 8, i8 0, i8 0, i8 0 }, align 16
declare void @llvm.assert(i1)
define <4 x i32> @f(<4 x i32> %0) local_unnamed_addr {
arm_tv_entry:
%a8_2 = load i64, ptr inttoptr (i64 add (i64 ptrtoint (ptr @.LCPI0_0 to i64), i64 8) to ptr), align 8
%1 = bitcast <4 x i32> %0 to <2 x i64>
%a8_4 = insertelement <2 x i64> %1, i64 %a8_2, i64 1
tail call void @llvm.assert(i1 true)
tail call void @llvm.assert(i1 true)
tail call void @llvm.assert(i1 true)
tail call void @llvm.assert(i1 true)
tail call void @llvm.assert(i1 true)
tail call void @llvm.assert(i1 true)
tail call void @llvm.assert(i1 true)
tail call void @llvm.assert(i1 true)
tail call void @llvm.assert(i1 true)
tail call void @llvm.assert(i1 true)
tail call void @llvm.assert(i1 true)
%2 = bitcast <2 x i64> %a8_4 to <4 x i32>
ret <4 x i32> %2
} |
happily, I can now verify the AArch64 backend's translation of this kind of function:
however, a roundtrip through integer causes it to fail validation:
the generated ARM is the same in both cases:
of course the lifted code is the same in both cases:
here's the failing output:
The text was updated successfully, but these errors were encountered: