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).
I don't think the interface on this is quite right. You have the new utility exposing a new instance of the GCStrategy object. I would expect each GCStrategy to be a singleton. (i.e. having two "statepoint-example" GCStrategy instances would seem surprising.)
I think you need to move the ownership of GCStrategy objects from GCMetadata to LLVMContext, and then cache the lookup. You want to leave GCStrategyList in place, but probably make it non-owning.
What's the problem of having multiple instances of the same GC strategy? Currently, each strategy has only const methods, so it doesn't matter which instance we are using. Even if we make them mutable, isn't it possible that we are willing to get some default strategy and then configure it, e.g., depending on a platform? In that case, having different instances is even useful.
These are currently singleton objects; I'd like to preserve that. It would be reasonable for a custom strategy to e.g. cache computation in mutable state, and having two or more copies breaks that reasonable implementation in hard to predict ways.
If you think this is too large an ask implementation wise, say so. I'm not strongly tied to it, it's simply a mild preference.
Why are they singleton objects now? In current code, they are instatiated as many times as getGCStrategy is called, and it's called once for every function in module from GCFunctionInfo &GCModuleInfo::getFunctionInfo(const Function &F) (if I'm reading this correctly). Am I missing something here?
You are missing something.
GCModuleInfo::getGCStrategy maintains a map from name to GCStrategy object. If you look up the same name repeatedly (e.g. for every function), you get the same GCStrategy object. There is currently one object per GC name.
So it's not a singleton, it's something that is cached inside of GCModuleInfo. If you have 2 different instances of GCModuleInfo, you will have two different GCStrategies with same name. And this patch preserves this behavior.
You can as well say that SCEV constant 1 of type i32 is a singleton, but it's not: it is something that is cached within a particular instance of ScalarEvolution.
Even if this thing was a singleton, I don't believe it's important for any practical purpose.