jeanPerier added a comment.
Hi @pengfei, I am working on flang, and after this patch, we started to see
some bugs in Fortran programs using REAL(2) (which is fp16 in flang). I am not
an expert in LLVM codegen and the builtins, but I am wondering if there is not
issue with how llvm codegen thinks `__truncsfhf2` returns its value and how the
runtime actually does return it.
Here is an llvm IR reproducer for a bug we saw:
define void @bug(ptr %addr, i32 %i) {
%1 = sitofp i32 %i to half
store half %1, ptr %addr, align 2
ret void
}
After this patch the generated assembly on X86 is:
bug: # @bug
push rbx
mov rbx, rdi
cvtsi2ss xmm0, esi
call __truncsfhf2@PLT
pextrw eax, xmm0, 0
mov word ptr [rbx], ax
pop rbx
ret
When running this from a C program to test integers are casted to floats, I am
only seeing the bytes of the passed address being set to zero (regardless of
the input). It seems to me that there is an issue around the `__truncsfhf2`
interface. The `pextrw eax, xmm0, 0` after the call seems to suggest LLVM
codegen is looking for the result in xmm0 register, but it seems that
`__truncsfhf2` is only returning it in eax.
Do you have any idea what could be the issue ?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D107082/new/
https://reviews.llvm.org/D107082
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
