karthik-man wrote:
I am debugging a Triton issue
(https://github.com/triton-lang/triton/issues/4060), where an {i32, i32, i32,
i64} struct passed to _vprintf_ is printing the wrong value for the i64. The
issue here seems to be that Triton creates a llvm:Module with a default
DataLayout. In the default layout, i64 abi alignment is 4(DefaultAlignments in
DataLayout.cpp). This causes the optimization in this PR to rewrite the GEP to
the i64 as follows:
`%8 = alloca { i32, i32, i32, i64 }, align 8`
`%12 = getelementptr { i32, i32, i32, i64 }, ptr %8, i32 0, i32 3`
to
`%6 = alloca { i32, i32, i32, i64 }, align 8`
`%9 = getelementptr inbounds i8, ptr %6, i64 12`
But _vprintf_ expects the i64 to be at offset 16.
Is it legal for InstCombine to assume that the DL attached to the Module is the
right DL for the target? In other words, is it ok for InstCombine to do
optimizations that are target-dependent?
https://github.com/llvm/llvm-project/pull/68882
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
