-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Add f80 #10639
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
Add f80 #10639
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look great 👍
Should calls to compiler-rt on vectors be generated as unrolled or regular loops?
I suggest unrolled, since vectors lengths are generally small numbers. I think the lang spec will allow an implementation to do either way and still be correct.
341606c
to
84867ef
Compare
Some behavior tests to go along with this would be lovely. |
3383602
to
9464657
Compare
bc60d8f
to
e6f7adc
Compare
this branch now contains hacks, that need to be removed before merging
Looks like the branch is tripping an LLVM assert. This can be reproduced by building against a debug build of LLVM:
|
LLVM bitcast wants integers that match the number of bits. So the const bitcast has to use an i80, not an i128. This commit makes the behavior tests fail for me, so it seems I did not correctly construct the type. But it gets rid of the LLVM segfault. I noticed that the strategy of memcpy the buf worked if I simply did an LLVMConstTrunc() on the i128 to make it into an i80 before the LLVMConstBitCast(). But is that correct in the face of different endianness? I'm not sure.
this way passes the behavior tests
As discussed in Vexu/arocc#213 (comment)
Should calls to compiler-rt on vectors be generated as unrolled or regular loops?