How to use Module while designing a language?

[lanistor]

I'm designing a JIT VM for a language using LLJIT.
There may be hundreds of files wroten in the new language(considering a JVM in a web server) should i create a new Module for each file, or only create one Module for whole project?
I known two design schemes all works, but i don't known which is better?

[Naville]

IMHO, Clang and other frontends usually create a module for each translation unit (File in your case)

[lanistor]

@Naville If so, i need to import the global modules to every translation unit, the global modules are lots of c++ functions, those will link with IR while running, i'm worrying about the performance.

[joker-eph]

I assume your "global modules" with "lots of C++ functions" is the runtime for your system? You could just have this pre-compiled and made available to the JIT (just like libc functions are available).

You only need to load them in the IR if you want to inline some code into the code you're jitting.

[lanistor]

@joker-eph Thanks for reply. I don't understand clearly fornow.
You said have this pre-compiled and made available to the JIT , then load them, as my way of understanding:

1. Compile my c++ files' code and add global mapping to JIT.
2. Then using module asm to include their header files' definition into current module.

Is this right?

[Naville]

@joker-eph Thanks for reply. I don't understand clearly fornow.
You said have this pre-compiled and made available to the JIT , then load them, as my way of understanding:

1. Compile my c++ files' code and add global mapping to JIT.
2. Then using module asm to include their header files' definition into current module.

Is this right?

I think he means that shipping the library (binary code) and add them as global mapping. Then if you are JIT-ting from source, add header/function definitions to the compiler

[lanistor]

@Naville Yes, i understand, what my problem focused is the way to add header/function definitions to the compiler, is add definitions to the compiler meaning add definitions to every module?

[lhames]

Hi Vifird,

@Naville If so, i need to import the global modules to every translation unit, the global modules are lots of c++ functions, those will link with IR while running, i'm worrying about the performance

Are you worried about pulling in declarations from your global module? Or definitions? And are the global modules built from C++, or from your own language, or both?

I would not worry about the performance of declarations unless it shows up as a performance issue in real programs. If that happens you can try to make your global module import process more clever (e.g. import declarations on demand, rather than importing everything).

In general you should not pull in regular (non-weak/ODR) definitions from your global modules. As @joker-eph suggested these should be pre-compiled, and either linked into your binary (and made visible to JIT’d code via a DynamicLibrarySearchGenerator) or they should be added to your JIT at startup time. E.g.

auto J = ExitOnErr(LLJITBuilder::create());
ExitOnErr(J->addObjectFile(ExitOnErr(MemoryBuffer::getFile(“/path/to/lib.o”))));

The only exception to this is if you want to be able to inline global function definitions into your JIT’d code. In this case I would pre-compile the globals as above, then add copies of the definitions to each module where they are used and set the linkage for those copies to GlobalValue::AvailableExternallyLinkage. Available-externally linkage means that the function definition is available for inlining and optimization at the IR level, but will be discarded by the code generator). You get the optimization benefit of having the definition present, but you don’t have to worry about code-generation cost or memory consumption for the copies.

If you’re concerned about pulling in weak or ODR definitions from C++ template instantiations there are two things to know:

(1) By default ORC will detect redundant ODR definitions and change their linkage to AvailableExternally for you.

(2) You can override the default (By writing your own simple IRLayer) to discard redundant ODR definitions immediately. This trades away some optimization opportunities for more up-front memory savings (by not holding the uncompiled IR definitions).

You need to do a performance analysis on representative benchmarks to decide which is better for you, but I would stick with (1) (the default) until/unless you see significant memory pressure from the extra definitions.

I hope this helps. Let me know if I have misunderstood your question.

[lanistor]

@lhames Thanks a lot, that's exactly what i want to know.