[PATCH] D86262: [LoopIdiomRecognizePass] Options to disable part or the entire Loop Idiom Recognize Pass

[Anh Tuyen Tran via Phabricator via llvm-commits]

anhtuyen added a comment.

In D86262#2228451 <https://reviews.llvm.org/D86262#2228451>, @lebedev.ri wrote:

> In D86262#2228420 <https://reviews.llvm.org/D86262#2228420>, @anhtuyen wrote:
>
>> In D86262#2227781 <https://reviews.llvm.org/D86262#2227781>, @dfukalov wrote:
>>
>>> In D86262#2227676 <https://reviews.llvm.org/D86262#2227676>, @lebedev.ri wrote:
>>>
>>>> Why not just enhance DA?
>>>
>>> I agree with that, it seems to be better to improve DA. Is it feasible?
>>
>> I agree that DA can be improved, but I hope that the example below from @nemanjai  about libraries, which are highly tuned with respect to when/whether to call memset/memcpy functions provides another reason for this proposed change.
>
> I'm not really sold on this. We have similar transform in InstCombine.
> If the original problem is with DA, then that is what should be improved.
>
> If this transform is a pessimization for some code, it would be good to actually see that code.

I hope you find the detailed comment below by @bmahjour (thanks, @bmahjour) below a reasonable ground for this change.

> The theory of data dependence analysis relies on presence of subscripts in array references to be able to produce accurate results. I don't see how we can "improve DA" to address memset/memcpies short of turning them back into loop nests before applying the dependence tests. To do that the loop has to either be materialized before the DA analysis pass is run, or somehow SCEV expressions representing the implied subscripts be synthesized out of thin air. The former must be achieved by a transformation pass, so we would have to turn memset/memcpys into loop nests as soon as possible. For memset/memcpy calls generated by the loop idiom pass, the ideal place for that transformation would be immediately after loop idiom itself, which would have the same effect as preventing loop idiom from creating such loops in the first place when it knows they are not profitable. I don't know of any possible way to do the latter.
>
> I agree with @fhahn that this is more of a cost-modeling issue. I think the cost-modeling would have to rely heavily on loop tripcount data which, in the general case, is only available through PGO, so an option to disable it for users who don't want to use PGO makes sense to me.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86262/new/

https://reviews.llvm.org/D86262