-
Notifications
You must be signed in to change notification settings - Fork 205
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
Migrate to opaque pointers #553
Comments
This is now required as LLVM 15 has removed non-opaque pointers: https://releases.llvm.org/15.0.0/docs/ReleaseNotes.html#changes-to-the-llvm-ir |
This comment was marked as spam.
This comment was marked as spam.
@rongduo you seem to be using an auto-responder on this issue tracker. Please stop. This is creating spam on the issues. I've seen this several times now and will need to block you if you don't disable the auto-responder. |
Actually, it looks like we're going to be forced to straddle this change. According to the official documentation, opaque pointers in LLVM 14 are not production ready. So we'll need to keep the non-opaque code paths until we support LLVM 15+ only. |
The first part of this migration went into #639. I think at this point, there is only one nontrivial place in the code where we need pointer types: Lines 601 to 603 in 8f43bed
This occurs in the context of trying to get external types out of Clang. Basically, we define a function that includes all of these types as arguments, and then when we need one, we grab that function and fetch the Lines 598 to 600 in 8f43bed
If you look for Lines 147 to 155 in 8f43bed
We're basically building a list of types: Lines 122 to 127 in 8f43bed
And we build a function with all the types as parameters: Lines 501 to 524 in 8f43bed
It's not totally clear to me whether we're hitting this line or not, but we may also be doing some magic to keep the function itself alive (or this might be for other functions): Lines 483 to 484 in 8f43bed
Anyway, it's not obvious to me how to replace this machinery. The types we're passing to the function are all I think there are two things that a solution needs to accomplish:
However, since I had to disable this code path in the past for other targets, I should also try disabling this conditional and see if we can get away with just not reusing the types at all: Lines 595 to 597 in 8f43bed
I.e., treating every target as a non-native target. |
We finished this in #643. |
Recent LLVM versions have begun migrating to opaque pointers, i.e., pointers with no type. Notably, LLVM 14 added versions of
CreateLoad
etc. that require an explicit type argument (as the element type is no longer specified in the pointer type).For now, non-opaque pointers aren't actually gone so we can rely on the old code paths. But presumably at some point LLVM will pull the plug and we'll need to migrate.
My initial effort to do the migration didn't go so well because there are a bunch of corner cases. Not all types are clearly labeled in the compiler, and sometimes they seem to be missing entirely (because we're relying on pointers to carry that information). So in order to work in a world with opaque pointers, we need to track all of that and make sure we don't lose it as it's going down the stack.
The text was updated successfully, but these errors were encountered: