RFC: Can we make TargetTransformInfo an analysis group?

I know, I said a bad word – analysis group.

But it works pretty much the way I think we want here. We always want a TargetTransformInfo, and we have reasonable (conservative) stubs in place. We would just like the option of providing one from the target that has very clever implementations.

I would propose that we make TargetTransformInfo be an analysis group, and provide NoTargetTransformInfo as the shim implementation, and each target provide the more detailed one. This will allow consumers to use normal getAnalysis methods, etc.

As part of this, I’m planning to move all of TargetTransformInfo to lib/Analysis.

I’d like to do this soon, so speak up if this sounds like a bad idea. =]
-Chandler

I know, I said a bad word -- analysis group.

But it works pretty much the way I think we want here. We *always* want a TargetTransformInfo, and we have reasonable (conservative) stubs in place. We would just like the option of providing one from the target that has very clever implementations.

I just want to make sure that targets could implement a subset of the implementation and fallback to the default implementation when needed.

For example the function below uses the default implementation for most cases and only handles abnormal instructions:

X86VectorTargetTransformInfo::getArithmeticInstrCost in https://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86ISelLowering.cpp?view=markup

I would propose that we make TargetTransformInfo be an analysis group, and provide NoTargetTransformInfo as the shim implementation, and each target provide the more detailed one. This will allow consumers to use normal getAnalysis methods, etc.

As part of this, I'm planning to move all of TargetTransformInfo to lib/Analysis.

I'd like to do this soon, so speak up if this sounds like a bad idea. =]
-Chandler

It sounds like a good idea. I like it.