Skip to content
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

Closed
llvmbot opened this issue Dec 9, 2009 · 5 comments
Closed

lazy loading from bitcode shouldn't abuse linkage #6109

llvmbot opened this issue Dec 9, 2009 · 5 comments
Labels
bugzilla Issues migrated from bugzilla llvm:core

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Dec 9, 2009

Bugzilla Link 5737
Resolution FIXED
Resolved on Jan 27, 2010 14:47
Version trunk
OS All
Blocks #6107
Reporter LLVM Bugzilla Contributor

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.

@lattner
Copy link
Collaborator

lattner commented Dec 9, 2009

Retitling. The right fix is to kill off ghost linkage, which has always been a hack.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Dec 10, 2009

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.)

@llvmbot
Copy link
Collaborator Author

llvmbot commented Dec 10, 2009

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?

@llvmbot
Copy link
Collaborator Author

llvmbot commented Jan 23, 2010

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.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Jan 27, 2010

Fixed in r94686.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla llvm:core
Projects
None yet
Development

No branches or pull requests

2 participants