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
lazy loading from bitcode shouldn't abuse linkage #6109
Comments
Retitling. The right fix is to kill off ghost linkage, which has always been a hack. |
Is the fix to replace this with a function attribute denoting its rematerializability? Or a different redesign where you can query the Function-ModuleProvider pair? (I'd prefer the materialize method be on Function, not the MP.) |
I'd suggest adding a ModuleProvider* to the Module (reversing the ownership relation), and moving ModuleProvider::materializeFunction() to GlobalValue::Materialize(). The function currently named GlobalValue::hasNotBeenLoadedFromBitcode() could be renamed GlovalValue::materializable() and could either query getParent()->getMP()->some_dense_map or cache that result in an attribute. Similarly, ModuleProvider::dematerializeFunction() would move to GlobalValue::Dematerialize(). The current BitcodeReader implementation assert-fails when the function wasn't originally loaded from bitcode, but it would be nice to either return false when the function wasn't dematerializable or have a GlobalValue::dematerializable() query method. ("dematerializable" or "rematerializable"?) Thoughts? |
I have a preliminary fix at http://codereview.appspot.com/193064. I still need to proofread it and check whether it immediately fixes #6107 , but this is the overall direction I'm proposing. Comments are welcome. I'll ping when it's ready for final review. |
Fixed in r94686. |
Extended Description
Before a function has been lazy-loaded from bitcode, its linkage is 'ghost'. When the JIT needs the address of an available_externally function, it needs to dlsym it from the main executable, but it has to waste time loading the function from bitcode to determine that it doesn't need any of the IR it just loaded.
If 'ghost' or 'available_externally' were something other than a linkage, this wouldn't be a problem.
The text was updated successfully, but these errors were encountered: