-
Notifications
You must be signed in to change notification settings - Fork 10.9k
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
[ORC] Missing definition for inlining function after optimizations in IRTRansformLayer #64907
Comments
@llvm/issue-subscribers-orcjit |
I've been doing more digging and was able to replicate this with different functions that do not include the The common denominator here seems to come from the linkage type: |
It's not usually safe to remove symbols from the interface of a I think we should probably change |
Actually after talking to @ributzka I think the better option might be to leave ORC has a provision for weak symbols that "show up late", e.g. weak definitions of constant pool entries produced during codegen -- we could use this to model |
This commit makes three changes: 1. Unify symbol mapping into IRLayer and discard the old IRSymbolMapper class 2. Allow for clients to provide their own symbol mapper function to provide custom mappings 3. Skip adding linkonce_odr symbols to the symbol map on the default mapper (fixes llvm#64907)
Faced this issue while dealing with an optimization pipeline that focuses on inlining.
If a function has the
always_inline
attribute andlinkonce_odr
linkage, it is registered as a symbol for materialization by the MU. After optimization, passes discard the definition in IR and no symbol is generated. The symbol request is then left dangling by the MU.Quick module to reproduce:
I have not done in-depth testing, but I'm pretty sure any standard optimization pipeline done by the new pass manager would trigger this, as the function is marked as
always_inline
.The text was updated successfully, but these errors were encountered: