GC strategies are registered using a system of global constructors: any
object can include a GCRegistry::Add stataic variable to register a
strategy, and that will generate a static constructor which registers
this strategy into a global list.
This allows shared libraries to easily register their own strategies,
but poses a problem related to linking: the default GC strategies
(defined and registered in their own file) must obviously be included in
LLVM binaries.
The previous solution was to define an empty functon in BuiltinGCs.cpp,
and call it from LinkAllCodegenComponents.h - this is the solution used
for many other codegen components. This header is then included into the
llc and lli main source files, ensuring everything gets linked into
those binaries.
This isn't great for GCStrategy, which we'd like [1] to use in other
binaries, notably opt for the RS4GC [2] pass. Instead of doing something
specific to opt (for example, adding a call in LinkAllIR), this patch
links to the registry function from getGCStrategy, in the assumption
that anything that might look up a GC strategy probably also expects
the default strategies to exist.
[1] https://reviews.llvm.org/D140458
[2] RewriteStatepointsForGC
Differential Revision: https://reviews.llvm.org/D140504
This patch fixes the following error with MSVC 16.9.2:
llvm/lib/IR/GCStrategy.cpp(35): error C2668: 'llvm::report_fatal_error': ambiguous call to overloaded function
llvm/include/llvm/Support/ErrorHandling.h(75): note: could be 'void llvm::report_fatal_error(const llvm::Twine &,bool)'
llvm/include/llvm/Support/ErrorHandling.h(73): note: or 'void llvm::report_fatal_error(llvm::StringRef,bool)'
llvm/lib/IR/GCStrategy.cpp(35): note: while trying to match the argument list '(const std::string)'
Reviewed By: RKSimon, barannikov88
Differential Revision: https://reviews.llvm.org/D130407
We might want to use info from GC strategy in middle end analysis.
The motivation for this is provided in D99135: we may want to ask
a GC if it's going to work with a given pointer (currently this code
makes naive check by the method name).
Differetial Revision: https://reviews.llvm.org/D100559
Reviewed By: reames
We want it to be available in analyzes so that we could use the
CodeGen notion in middle-end passes (for example, to check if
a GC may free some particular pointer).
This is a preparatory patch that simply moves the files around.
Note: if this causes some build issues, this patch must just be reverted.
Differential Revision: https://reviews.llvm.org/D100557
Reviewed By: reames
This change reverts the interesting parts of 226311 (and 227046). This change introduced two problems, and I've been convinced that an alternate approach is preferrable anyways.
The bugs were:
- Registery appears to require all users be within the same linkage unit. After this change, asking for "statepoint-example" in Transform/ would sometimes get you nullptr, whereas asking the same question in CodeGen would return the right GCStrategy. The correct long term fix is to get rid of the utter hack which is Registry, but I don't have time for that right now. 227046 appears to have been an attempt to fix this, but I don't believe it does so completely.
- GCMetadataPrinter::finishAssembly was being called more than once per GCStrategy. Each Strategy was being added to the GCModuleInfo multiple times.
Once I get time again, I'm going to split GCModuleInfo into the gc.root specific part and a GCStrategy owning Analysis pass. I'm probably also going to kill off the Registry. Once that's done, I'll move the new GCStrategyAnalysis and all built in GCStrategies into Analysis. (As original suggested by Chandler.) This will accomplish my original goal of being able to access GCStrategy from Transform/ without adding all of the builtin GCs to IR/.
llvm-svn: 227109
Note: This change ended up being slightly more controversial than expected. Chandler has tentatively okayed this for the moment, but I may be revisiting this in the near future after we settle some high level questions.
Rather than have the GCStrategy object owned by the GCModuleInfo - which is an immutable analysis pass used mainly by gc.root - have it be owned by the LLVMContext. This simplifies the ownership logic (i.e. can you have two instances of the same strategy at once?), but more importantly, allows us to access the GCStrategy in the middle end optimizer. To this end, I add an accessor through Function which becomes the canonical way to get at a GCStrategy instance.
In the near future, this will allows me to move some of the checks from http://reviews.llvm.org/D6808 into the Verifier itself, and to introduce optimization legality predicates for some of the recent additions to InstCombine. (These will follow as separate changes.)
Differential Revision: http://reviews.llvm.org/D6811
llvm-svn: 226311
