[llvm-dev] Question about Traversing Loops in forward or reverse program order on new pass manager

Fri Apr 16 14:58:00 PDT 2021

Do you remember what the locality was of that was the factor?

Right now we’re running a loop pass on each loop, which isn’t very different from running a function pass on each loop in a function, so in that sense we keep the “same code different data” format.  Was it the loop structure that was only computed once-ish that made the difference?

My concern is that there are multiple traversal dimensions, not only forward/backward, but also “innerward”/”outerward”, plus optimizing one loop may affect the next one.  I think that more “holistic” passes would provide better flexibility.

--
Krzysztof Parzyszek  kparzysz at quicinc.com<mailto:kparzysz at quicinc.com>   AI tools development

From: Philip Reames <listmail at philipreames.com>
Sent: Friday, April 16, 2021 3:52 PM
To: Krzysztof Parzyszek <kparzysz at quicinc.com>; Arthur Eubanks <aeubanks at google.com>; Jingu Kang <Jingu.Kang at arm.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] Question about Traversing Loops in forward or reverse program order on new pass manager

On 4/15/21 10:27 AM, Krzysztof Parzyszek via llvm-dev wrote:
I think the traversal order may depend on the optimization.  I would actually propose to get rid of those fine-grained pass managers altogether.  I think they are abstractions taken too far, to the point of being counter-productive.  Instead, loop passes should visit a function at a time, and use utility functions (like iterators of various kinds) to visit loops in the order they want.

JFYI, there are very good compile time reasons to visit each loop with all passes.  I don't remember the exact numbers, but I remember last time this was assessed that locality made a very measurable impact.  Particularly for large machine generated codebases.

If we do have loop transforms which prefer both, we could do two pass approach.  We have something analogous to this for inferring attributes in IPO.

On the actual issue here, I think we should stick to the old traversal order for the time being.  This would reduce the potential for regressions and make it easier to fully transition to the NPM for everyone.

--
Krzysztof Parzyszek  kparzysz at quicinc.com<mailto:kparzysz at quicinc.com>   AI tools development

From: llvm-dev <llvm-dev-bounces at lists.llvm.org><mailto:llvm-dev-bounces at lists.llvm.org> On Behalf Of Arthur Eubanks via llvm-dev
Sent: Thursday, April 15, 2021 11:59 AM
To: Jingu Kang <Jingu.Kang at arm.com><mailto:Jingu.Kang at arm.com>
Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] Question about Traversing Loops in forward or reverse program order on new pass manager

Ping on loop traversal order. Does anybody have any intuition about which way to traverse loops in a function?

On Wed, Apr 7, 2021 at 12:36 PM Jingu Kang via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hi All,

I have seen performance regressions from new pass manager against legacy pass manager. One of the issues is the order of populating loops on pass manager. The legacy pass manager is traversing loops in reverse program order but the new pass manager is traversing in forward program order. It sometimes causes different output. I have created a review https://reviews.llvm.org/D99774 for reverse program order on new pass manager and had short discussion with Arthur on it. It is not easy to say the reverse order is better than the forward one or vice versa. I would like to share this issue with more people on llvm-dev. If you have idea or experience about this issue, please share it.

Thanks
JinGu Kang
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________

LLVM Developers mailing list

llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>

https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210416/cc908381/attachment-0001.html>