[PATCH] D28694: Hexagon-specific loop idiom recognition

[Krzysztof Parzyszek via Phabricator via llvm-commits]

kparzysz added inline comments.


================
Comment at: lib/Transforms/IPO/PassManagerBuilder.cpp:320
+  addExtensionsToPM(EP_LoopIdiom, MPM);
+
   MPM.add(createLoopIdiomPass());             // Recognize idioms like memset.
----------------
mehdi_amini wrote:
> hfinkel wrote:
> > mehdi_amini wrote:
> > > This extension point could get its own separate patch.
> > > 
> > > It seems very targeted, if the only point is to have TargetSpecific loop idiom recognition, then why aren't some TTI implemented and used in LoopIdiomPass?
> > I thought about suggesting this, but didn't because:
> > 
> >  a. It is not clear what from the existing loop idiom recognition pass could be reused
> >  b. The target-specific logic might want access to other analyses, and that would be awkward if it is just a TTI callback.
> > 
> > What do you think?
> > 
> These are good points!
> 
> > It is not clear what from the existing loop idiom recognition pass could be reused
> 
> Main point here: the insertion point in the pipeline :)
> 
> >  The target-specific logic might want access to other analyses, and that would be awkward if it is just a TTI callback.
> 
> No sure what you mean by "awkward" with a TTI needing analysis, but that would definitely be a problem if the TTI would want an analysis that is not generic or not currently available in LoopIdiom.
> 
> The reason I think discussing this extension point in its own revision is because I think we usually have "generic" and "coarse grain" extension points (do we have another case of specific hook like that?).
> I'm cautious about it because adding such hooks makes it harder to evolve/maintain the pipeline (ultimately what when we'll have a hook before/after every single pass?).
> I'm cautious about it because adding such hooks makes it harder to evolve/maintain the pipeline (ultimately what when we'll have a hook before/after every single pass?).

That's an understandable concern, but I think that this particular case is warranted, since it is not uncommon for targets to have their optimized versions of certain loop-based operations.  It can be either via target-specific runtime libraries, or directly via hardware instructions.
Since this insertion point is shared with that of the target-independent loop idiom recognizer, the implementations would also share the same ways of handling the code.  That would make it easier to move code from a target-specific version to the target-independent pass, or conversely, to take a target-independent code and adopt it for the needs of a given target.


Repository:
  rL LLVM

https://reviews.llvm.org/D28694