intrinsics: Implement arbitrary-width integer intrinsics in C#61399
intrinsics: Implement arbitrary-width integer intrinsics in C#61399topolarity merged 3 commits intoJuliaLang:masterfrom
Conversation
topolarity
changed the title
topolarity
force-pushed
the
ct/intrinsics-no-LLVM
branch
4 times, most recently
from
105f048 to
be217e3
Compare
topolarity
force-pushed
the
ct/intrinsics-no-LLVM
branch
2 times, most recently
from
92b5f92 to
4d0195e
Compare
|
I did a barrage of testing today, primarily externally using Python and also internally by comparing to LLVM / codegen. This seems to be a net improvement in terms of bugs now. Certainly it is in terms of test coverage. I will probably add a few more tests on Monday, but this should be nearly ready to go. |
|
How are we guaranteed to go through the intrinsics on your tests? |
The We do have a bit of dispatching in |
|
i686 failures due to #61436 |
topolarity
force-pushed
the
ct/intrinsics-no-LLVM
branch
from
4d0195e to
e317048
Compare
These are one of the remaining reasons that we have to link against LLVMSupport in `libjulia-internal`, and it turns out that it's not that difficult to provide a replacement implementation for this. Largely one-shot by Claude, although I had to guide it to merge overlapping implementations and consider sign bits carefully in a couple of places. The main performance trade-off versus the LLVM implementation is that this implements "schoolbook" multiplication / division, rather than accelerated algorithms (I believe LLVM provides Knuth's "Algorithm D"). However these intrinsics are used only rarely as a runtime / interpreted fallback to native execution of these intrinsics via LLVM codegen, so I doubt these are performance-sensitive functions in practice. Also fix a bug in `jl_intrinsiclambda_checked` that caused the "overflow" bit to be written to the wrong location for non-power-of-two primitive types. --------- Co-authored-by: Claude <claude@anthropic.com>
This adds a number of tests for our runtime and compile-time intrinsics implementations. This primarily checks the implementations against each other, rather than testing them directly. Nonetheless, it should provide decent confidence to catch regressions from the port to C. The various bugs found and fixed today (by comparison to Python) are all caught by these tests too. --------- Co-authored-by: Claude <claude@anthropic.com>
topolarity
force-pushed
the
ct/intrinsics-no-LLVM
branch
from
59773a9 to
33f6904
Compare
|
CI looks green, and I am happy with the test coverage. I will merge this soon (in absence of any objections) |
oscardssmith
left a comment
oscardssmith
left a comment
There was a problem hiding this comment.
Implimentation looks reasonable.
|
Thanks for the review @oscardssmith |
oscardssmith
added
maths
3 participants
@gbaraldi 's work in #61292 makes a big step towards removing our dependency on
LLVMSupportinlibjulia-internal(saving on size for--trimapplications). This PR takes another step by removing our dependency on LLVM for our arbitrary-precision integer intrinsics.The main performance trade-off versus the LLVM implementation is that this implements "schoolbook" multiplication / division, rather than accelerated algorithms (I believe LLVM provides Knuth's "Algorithm D"). These intrinsics are used only rarely as a runtime / interpreted fallback to native execution of these intrinsics via LLVM codegen, so I doubt these implementations are performance-sensitive in practice.
This PR is significantly generated by AI 🤖. Largely one-shot by Claude, although I had to guide it to merge overlapping implementations and consider sign bits (edit: and rounding) carefully in a couple of places. Tested locally with a combination of hand-written, AI-generated, and machine-generated tests (a subset of these will be added to the PR soon).
Resolves #61421, Resolves #61419, Resolves #61423