[PATCH] D28694: Hexagon-specific loop idiom recognition
Krzysztof Parzyszek via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Jan 16 10:20:38 PST 2017
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
More information about the llvm-commits
mailing list