Hello,
In the thread about target-specific AA, Hal proposed some ideas regarding the interface connecting target-specific functionality with the target-independent pass manager. His post did not get any replies on the list, but I think it's interesting enough to get a second look. The copy of it is at the bottom of this email.
I am particularly interested in the possibility of adding target-specific passes to the optimization pipeline via the extension mechanism.
Does anyone have any comments or suggestions (or objections?) regarding the approach described below?
-Krzysztof
>
> I've cc'd Chandler so he can comment here.
>
> Currently, TargetMachine can optionally return a TargetIRAnalysis object; this is then provided a function for which it can produce the actual TargetTransformInfo-derived object. TargetTransformInfoWrapperPass is the actual pass, and it just holds a pointer to the TargetIRAnalysis object.
>
> In our case, we'd like to provide the target a way to add some AA pass to take advantage of target-specific knowledge regarding address spaces, intrinsics, and other IR constructs whose meaning is completely target specific. I'm not sure how well it fits into this model.
>
> In addition, we have other use cases where targets want to add passes to handle target-specific things into the pipeline (⚙ D11782 RFC: Target-specific loop idiom recognition, for example, for doing target-specific loop-idiom recognition).
>
> Plus, we already have a mechanism for allowing extension of the optimization pipeline, and I think the best way of approaching this (which is also useful for other use cases), is to provide the targets the ability to use this mechanism. I understand that this could be ripe for abuse (so we'd need to be vigilant in watching the targets), but nevertheless, how about this:
>
> 1. Add a function to TargetMachine called, for example, registerPassManagerBuilderExtensions(PassManagerBuilder *PMB). This would need to be called, for example, by the code in EmitAssemblyHelper in Clang in tools/clang/lib/CodeGen/BackendUtil.cpp (just as it currently calls TM->getTargetIRAnalysis() and so that it can call createTargetTransformInfoWrapperPass) and also registers other extensions itself.
>
> 2. registerPassManagerExtensions's job will be to call PassManagerBuilder::addExtension (or addGlobalExtension) as appropriate.
>
> 3. Create a new extension point for AA passes, and call addExtensionsToPM inside PassManagerBuilder::addInitialAliasAnalysisPasses
>
> This will automatically cover a wide variety of use cases, including this one. Thoughts?