Skip to content

Fix some compiler error on LLVM 21#59946

Open
yuyichao wants to merge 2 commits intomasterfrom
yyc/llvm21
Open

Fix some compiler error on LLVM 21#59946
yuyichao wants to merge 2 commits intomasterfrom
yyc/llvm21

Conversation

@yuyichao
Copy link
Copy Markdown
Contributor

Remaining issues are the removal of EHFrameRegistrar class and manual locking interface for ThreadSafeContext. Some other deprecation warnings are also left as is for now.

vchuravy
vchuravy previously approved these changes Oct 24, 2025
@yuyichao
Copy link
Copy Markdown
Contributor Author

@yuyichao
Copy link
Copy Markdown
Contributor Author

For the eh frame registration issue, it seems that the ehframe register plugin doesn't have any customization hooks anymore so maybe we need to create our own plugin instead?

For the ThreadSafeContext issue, I currently worked around it by patching llvm. The usage patter is more restricted with the new API and I'm not 100% sure yet if the new API covers all the needs here.

@giordano giordano added external dependencies Involves LLVM, OpenBLAS, or other linked libraries compiler:llvm For issues that relate to LLVM labels Oct 24, 2025
@yuyichao yuyichao force-pushed the yyc/llvm21 branch 2 times, most recently from 30b9363 to ca8ce88 Compare October 24, 2025 22:09
@giordano giordano mentioned this pull request Oct 24, 2025
@yuyichao yuyichao force-pushed the yyc/llvm21 branch 2 times, most recently from c53adce to 2961412 Compare October 26, 2025 14:40
@yuyichao
Copy link
Copy Markdown
Contributor Author

EHFrame registrer should be fixed now and the only remaining issue is the API change for ThreadSafeContext. I'm convinced that it is not possible to support the new API as-is without getting rid of incompletemodules. All the other usages seems managable.

The comment suggests that incompletemodules is only necessary until jitlink can be used everywhere. Not sure if that can be done with LLVM 21 or if we need to carry a LLVM patch in the meantime.

@yuyichao
Copy link
Copy Markdown
Contributor Author

Here's the LLVM patch I used to get julia and LLVM.jl to build/load JuliaLang/llvm-project#51 .

@yuyichao
Copy link
Copy Markdown
Contributor Author

Actually I take that back. The incompletemodules usage isn't a problem, since the codegen param objects stored there are all unlocked. The early unlocking used in add_output, however, doesn't really work. It should be only an memory consumption issue though and I don't think it'll be a correctness issue.

@yuyichao
Copy link
Copy Markdown
Contributor Author

The early release of thread safe context in add_output is now fixed so this should be everything for dealing with C++ API change.

The implementation could probably be cleaner with C++20 co_routine since this is more-or-less a manual implementation of it...

@yuyichao yuyichao force-pushed the yyc/llvm21 branch 3 times, most recently from 22dec88 to bdc92a9 Compare October 27, 2025 19:45
@yuyichao
Copy link
Copy Markdown
Contributor Author

yuyichao commented Oct 27, 2025

I moved all the change that doesn't require a version check to other PR's. (#59965 is included due to otherwise merge conflict).

I assume the first few changes should be reasonably clear and uncontroversial (those are part of the original PR). I can split that out if needed as well.
The last two commits would need some review, including making the gc checker happy again...

vtjnash pushed a commit that referenced this pull request Nov 19, 2025
We already need to manually create a C compatible function pointer and
heap allocated data, might as well do so directly without another
indirection through std::function.

Noticed the callback during
#59946. It does not need to be an
non static `extern "C"` function and could even be a lambda.
@yuyichao yuyichao force-pushed the yyc/llvm21 branch 2 times, most recently from e691651 to 2a87b5d Compare December 5, 2025 14:51
oscardssmith pushed a commit that referenced this pull request Dec 11, 2025
Split out of #59946 to make it
hopefully easier to review.
Turn `add_output` into a manual co-routine
so that we can get out of the caller scope mid-call
to release the threadsafecontext lock early.
gbaraldi added a commit that referenced this pull request Mar 9, 2026
LLVM 21 removes `ThreadSafeContext::getLock()`, `::Lock`, and
`::getContext()`, replacing them with callback-based
`ThreadSafeContext::withContextDo(callback)`.

Add a `withContextDo` compatibility shim that works on both LLVM 20
(acquires lock + calls callback) and LLVM 21+ (delegates to the new
API). Update all callsites to use scoped locking through this shim
instead of manual lock/unlock.

Key changes:
- `jl_codegen_output_t` no longer holds a persistent `tsctx_lock`.
  All context access goes through `withContextDo`, with debug asserts
  ensuring `get_context()`/`get_module()` are only called inside the
  callback scope.
- `addOutput()` and `R->replace()` are called outside `withContextDo`
  to respect the lock hierarchy (TSC locks must be released before
  dispatching materialization units).
- `jl_create_ts_module` and `compileModule` use the free-function shim.
- `disasm.cpp` replaces `std::optional<ThreadSafeContext::Lock>` with
  the callback pattern.

Supersedes #59946.

Co-Authored-By: yuyichao <yyc1992@gmail.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
gbaraldi added a commit that referenced this pull request Mar 9, 2026
LLVM 21 removes `ThreadSafeContext::getLock()`, `::Lock`, and
`::getContext()`, replacing them with callback-based
`ThreadSafeContext::withContextDo(callback)`.

Add a `withContextDo` compatibility shim that works on both LLVM 20
(acquires lock + calls callback) and LLVM 21+ (delegates to the new
API). Update all callsites to use scoped locking through this shim
instead of manual lock/unlock.

Key changes:
- `jl_codegen_output_t` no longer holds a persistent `tsctx_lock`.
  All context access goes through `withContextDo`, with debug asserts
  ensuring `get_context()`/`get_module()` are only called inside the
  callback scope.
- `addOutput()` and `R->replace()` are called outside `withContextDo`
  to respect the lock hierarchy (TSC locks must be released before
  dispatching materialization units).
- `jl_create_ts_module` and `compileModule` use the free-function shim.
- `disasm.cpp` replaces `std::optional<ThreadSafeContext::Lock>` with
  the callback pattern.

Supersedes #59946.

Co-Authored-By: yuyichao <yyc1992@gmail.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
gbaraldi added a commit that referenced this pull request Mar 9, 2026
LLVM 21 removes `ThreadSafeContext::getLock()`, `::Lock`, and
`::getContext()`, replacing them with callback-based
`ThreadSafeContext::withContextDo(callback)`.

Add a `withContextDo` compatibility shim that works on both LLVM 20
(acquires lock + calls callback) and LLVM 21+ (delegates to the new
API). Update all callsites to use scoped locking through this shim
instead of manual lock/unlock.

Key changes:
- `jl_codegen_output_t` no longer holds a persistent `tsctx_lock`.
  All context access goes through `withContextDo`, with debug asserts
  ensuring `get_context()`/`get_module()` are only called inside the
  callback scope.
- `addOutput()` and `R->replace()` are called outside `withContextDo`
  to respect the lock hierarchy (TSC locks must be released before
  dispatching materialization units).
- `jl_create_ts_module` and `compileModule` use the free-function shim.
- `disasm.cpp` replaces `std::optional<ThreadSafeContext::Lock>` with
  the callback pattern.

Supersedes #59946.

Co-Authored-By: yuyichao <yyc1992@gmail.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
oscardssmith pushed a commit that referenced this pull request Mar 11, 2026
## Summary

- Add `withContextDo` compatibility shim for `ThreadSafeContext` API
changes in LLVM 21 (which removes `getLock()`, `Lock`, and
`getContext()` in favor of callback-based `withContextDo`)
- Replace all manual lock/unlock patterns with scoped `withContextDo`
callbacks across `jitlayers.h`, `jitlayers.cpp`, `aotcompile.cpp`, and
`disasm.cpp`
- Add `JLEHFrameRegistrationPlugin` for LLVM 21+ (which removes
`jitlink::EHFrameRegistrar`), using JITLink allocation actions for EH
frame registration
- Debug asserts ensure `get_context()`/`get_module()` are only called
inside `withContextDo` scope
- Lock hierarchy respected: TSC locks released before
`addOutput()`/`R->replace()` which can trigger materialization

Supersedes #59946 and #60358, forward-porting those changes to current
master.

## Test plan

- [x] Builds and passes smoke test on LLVM 20
- [x] Builds and passes smoke test on LLVM 21 (tested with libLLVM
21.1.2 JLL)
- [ ] CI

This pull request was written with the assistance of generative AI
(Claude).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

There is quite a few whitespace changes so ignoring it is quite helpful

---------

Co-authored-by: yuyichao <yyc1992@gmail.com>
Co-authored-by: Sam Schweigel <sam.schweigel@juliahub.com>
@giordano
Copy link
Copy Markdown
Member

Were all changes here incorporated into other PRs, or is there anything missing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

compiler:llvm For issues that relate to LLVM external dependencies Involves LLVM, OpenBLAS, or other linked libraries

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants