(original) (raw)
I'm not sure how robust the half support is on X86, clang should never generate it. I believe in llvm 11 it changed to pass in the lower 16 bits of an integer register instead of in a float register. What does "incorrect math operations" mean? We're emulating half precision with floats and a conversion function, I don't think it will always match exactly with what native half would do.
Do you have a more complete IR file for Windows that I can take a look at?
\~Craig
On Thu, Mar 4, 2021 at 9:45 PM Jason Hafer via llvm-dev <llvm-dev@lists.llvm.org> wrote:
Hello,
I am attempting to understand an anomaly I am seeing when dealing with half on Windows and could use some help.
Using LLVM 8 or 10, if I have IR of the flavor below:
define void @foo(i8, i8, i8, i8, half) {%6 = alloca half
store half %4, half\* %6, align 1...ret void}
Using x86\_64-pc-linux, we convert the float passed in with \_\_gnu\_f2h\_ieee.Using x86\_64-pc-windows I do not get the conversion, so we end up with incorrect math operations.
While investigating I noticed clang gave me the error below:
error: parameters cannot have \_\_fp16 type; did you forget \* ?
void foo(int dc1, int dc2,int dc3,int dc4, \_\_fp16 in)
So, this got me wondering if "define void @foo(i8, i8, i8, i8, half) " is even legal to use or if I should rather pass by ref? I have yet to find documentation to convince me one way or the other. Thus, I was hoping someone here might be able to shed some light on the issue.
Thank you in advance!
Cheers,
JP_______________________________________________
LLVM Developers mailing list
llvm-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev