Be able to jit functions that throw CAPI exceptions #814
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Which piggy-back on the integration tests for getting their dependencies.
Our IR doesn't explicitly represent the data transfer between an Invoke statement and its corresponding LandingPad. We use a couple different techniques to pass it through: in the ast interpreter/bjit, we stash it into an interpreter-local variable and then pull it back out. Previous to this change, in the LLVM tier we would pass it directly through an exception, using either the C++ or CAPI exception-passing mechanism. This works but is a pain, since it requires coordination between the invoke and the landingpad. These live in different basic blocks, so we ended up having this other code that lives separate from the normal irgen that has to decide which exception style to use, and it has to respect certain restrictions within irgen (ie it has to be careful to not request CAPI exceptions for cases that we haven't added support for yet). This commit changes the approach so that the exception data is passed directly as LLVM Values, and its up to the Invoke to figure out how to get it into that form. This adds a bit more complexity to the invoke, but it should make the interface easier to extend (such as in the next commit).
|
Oh I should mention, this new throw-capi-exceptions gets turned on if |
kmod
force-pushed
the
throw_capis3
branch
2 times, most recently
from
1941186 to
4224420
Compare
(Not enabled yet)
In theory should help with pyxl which throws a decent number of StopIterations from calling generator.next() directly, but pretty few of those calls actually make it into the llvm JIT to benefit from this.
kmod
added a commit
that referenced
this pull request
Aug 8, 2015
Be able to jit functions that throw CAPI exceptions
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A lot of our remaining C++ exceptions are being thrown from one Python frame and caught by another. We handle things caught by Python frames well, and this adds the ability to propagate them as CAPI exceptions.
I'm not stressing about the minor perf impact of these changes too much, but at least this set looks (randomly?) positive: