-
-
Notifications
You must be signed in to change notification settings - Fork 15k
Cross-crate inlining #1765
Copy link
Copy link
Closed
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.A-codegenArea: Code generationArea: Code generationA-frontendArea: Compiler frontend (errors, parsing and HIR)Area: Compiler frontend (errors, parsing and HIR)A-linkageArea: linking into static, shared libraries and binariesArea: linking into static, shared libraries and binariesC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.E-hardCall for participation: Hard difficulty. Experience needed to fix: A lot.Call for participation: Hard difficulty. Experience needed to fix: A lot.
Description
Metadata
Metadata
Assignees
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.A-codegenArea: Code generationArea: Code generationA-frontendArea: Compiler frontend (errors, parsing and HIR)Area: Compiler frontend (errors, parsing and HIR)A-linkageArea: linking into static, shared libraries and binariesArea: linking into static, shared libraries and binariesC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.E-hardCall for participation: Hard difficulty. Experience needed to fix: A lot.Call for participation: Hard difficulty. Experience needed to fix: A lot.
Type
Fields
Give feedbackNo fields configured for issues without a type.
We should be able to inline functions across crate boundaries. My current plan is to allow functions to be designated as inline. For such functions---along with generic functions---we will serialize the IR into the crate metadata. Then, when compiling, we will read out the IR as needed and instantiate a local version. Hopefully we can badger LLVM into doing the actual inlining for us.
I currently plan to serialize in EBML rather than pretty-printing. I believe this will be easier, because it will make it easy to encode the information found in various side tables (last use, etc). It will also allow us to preserve the line-number information, which strikes me as a requirement. It's basically some rote work that doesn't seem especially challenging. @pcwalton let me know if you think is really misguided. I will start today.
The bigger open questions are the "user interface" ones: should users designate inline functions explicitly? inline by default? I rather like the idea of being explicit about what might be inlined, since recompilation will be required for all clients if those functions change.