This avoids adding any additional global constructors, like cl::opt. There is a temporary exception on IR/, which has a few cl::opts that require a bit of plumbing to remove.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/IR/CMakeLists.txt | ||
---|---|---|
2 | This should be added to test/lib/ as well? |
mlir/lib/IR/CMakeLists.txt | ||
---|---|---|
2 | We could, but we don't really have a reason to limit what happens in tests do we? The motivation for doing this right now is about preserving the ability to build and embed the compiler in a product without having these ctors. |
mlir/lib/IR/CMakeLists.txt | ||
---|---|---|
2 | tests/lib is part of mlir-opt. Doesn't static init affect the latter's load time? |
mlir/lib/IR/CMakeLists.txt | ||
---|---|---|
2 | mlir-opt is a testing tool, not a production use-case. Unless there is a point where it measurably hinders developers velocity I'm not sure we should optimize for it. |
mlir/lib/IR/CMakeLists.txt | ||
---|---|---|
2 | mlir-opt is run roughly 1800 times each time 'check-mlir' is run and nearly all of them as you know are on small inputs. If static init has a noticeable impact on anything built with the libraries, it'll be noticed on check-mlir. We can actually verify it by timing check-mlir before and after this sequence of commits. |
mlir/lib/IR/CMakeLists.txt | ||
---|---|---|
2 |
I doubt it:
|
mlir/lib/IR/CMakeLists.txt | ||
---|---|---|
2 | I see - thanks! |
mlir/lib/IR/CMakeLists.txt | ||
---|---|---|
2 | Another thing we've been having an eye on is the ability to be able to use MLIR in an "embedded" environment: getting something like `int main() { context + pass manager + pass} to be as small as possible in term of binary size (this is also an argument to not have "fat" dialects but keep them in smaller pieces: when you register a dialect you get everything for all the ops even if you only use a subset of it). Something that we can't strip from the binaries at the moment are the parser/printer (and the custom one for every operation), this is also something that we may look into at some point: a production build of the compiler on the device does not need any printer/parser. |
This should be added to test/lib/ as well?