Skip to content

Cross-crate inlining #1765

Closed
Closed
@nikomatsakis

Description

@nikomatsakis

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.A-codegenArea: Code generationA-frontendArea: Compiler frontend (errors, parsing and HIR)A-linkageArea: linking into static, shared libraries and binariesC-enhancementCategory: An issue proposing an enhancement or a PR with one.E-hardCall for participation: Hard difficulty. Experience needed to fix: A lot.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions