similar to: Loop Opt WG Meeting Minutes for July 17, 2019

Thanks Florian. Tim you said: > Some cases can be undone by rematerialization, but not all, and it can involve a lot of effort which increases compile time. Do you have examples of cases where rematerialization is not possible? We are interested in learning about any previous attempts at trying to address the issue in RA. Have you tried it? Bardia Mahjour Compiler Optimizations IBM Toronto

--------------------------- Wed, Sep 11, 2019: --------------------------- - LICM vs Loop Sink Strategy (Whitney) - LICM and SCEV expander host code with no regards to increased live-ranges. This is a long standing issue where historically preference has been to keep LICM more aggressive. - Two questions from IBM side: a. This problem is not specific to the POWER

Thanks for sharing the known problem. I think to solve the problem properly, we need to fully understand why that assumption about dominance is there and the implications of removing it. It would be good if you could be more specific about your idea of nullptr or SCEV_unknown (eg which function would return those values and when), but returning nullptr from getAddExpr or getSCEVAtScope may be

Hi Jimmy, It's good to know that the problem is not specific to the case I ran into. May be you can provide your example as well, since Philip seems to be interested in some specific examples. If the assertion in getAddrExpr is deemed necessary, then I think a condition check would be the next best solution as it helps client code guard against such cases and make alternative arrangements to

> I'm not following your example.  If you have two sibling loops with the same parent, one will frequently, but not always dominate the other.  Can you give a specific example of when forming a recurrence between two siblings (without one dominating the other), is useful? The situation can happen with guarded loops or with a user guard like below: if (c) { for (i = 0; i < n; i++)

Forwarding to the dev list, in case others ran into similar issues and/or have input on this topic. Bardia Mahjour ----- Forwarded by Bardia Mahjour/Toronto/IBM on 2020/03/30 02:25 PM ----- From: Bardia Mahjour/Toronto/IBM To: listmail at philipreames.com Cc: "Michael Kruse" <llvm at meinersbur.de> Date: 2020/03/26 11:47 AM Subject: Scalar Evolution Expressions Involving Sibling

Hi David, Thank you very much for your response. I also get correct results for my example (for a 64-bit target) if the upper bounds are changed to unsigned. The reason is simply because clang zero-extends `m` for address calculations but sign-extends it for the loop upper bound. This prevents SCEV from canceling out the 'm' term from the difference expression that looks like `(-3 +

Hi all, When writing new passes we currently have two pass manager interfaces to consider. In many cases we resort to implementing both interfaces because the NPM is not enabled by default while we want our pass to be enabled by default. It is my understanding that the new pass manager interface is going to replace the old one soon. However, it is not clear to me if anyone is actively working on

Hello Under the proviso that it's been a while since I looked into any of these things... On 05/15, Bardia Mahjour via llvm-dev wrote: > I also get correct results for my example (for a 64-bit target) if the upper > bounds are changed to unsigned. The reason is simply because clang zero-extends > `m` for address calculations but sign-extends it for the loop upper bound. This >

Hello Yes, I agree that the SCEV cannot be simplified. Is my understanding correct that it is passed to a function like "isKnownNegative"? Which could still be able to prove is always true. The delinearisation may be valid, depending on exactly how you define delinearisation (under what conditions it should be giving results). It would be invalid for DA to return a dependency of [0

Agenda for the meeting of July 15 @ 11:00 am (EST): - Loop-Hierachical IR Representation Design (Michael Kruse) - Status Updates -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200713/44b826a0/attachment.html>

Hi all, I have been looking at the `DependenceAnalysis` pass in `llvm/include/llvm/Analysis/DependenceAnalysis.h`. In order for this analysis to produce accurate dependence vectors for multi-dimensional arrays in nested loops, it needs to "delinearize" array element accesses to recover the subscripts in each dimension of the array. I believe that the current implementation of

Dear LLVM community, we would like to form a working group that focuses on loop optimizations and the loop optimization pipeline in LLVM. This working group would meet at a regular cadence (weekly or bi-weekly depending on people's schedules) and discuss topics relevant to loop optimizations. These topics would include: - Implementation of current loop optimizations - Proposals for

Hi all, I am trying to use the dependence analyzer in a pass that I am writing and I was surprised to see an incorrect behavior when I try to query DependenceInfo for dependences between instructions. Specifically, if the two instructions are loads/stores accessing an array in a loop, the depend() method would return a dependence regardless of the order of instructions specified. (i.e. if the two

[CC bollu, mferguson, shil] Am Do., 23. Mai 2019 um 17:13 Uhr schrieb Bardia Mahjour < bmahjour at ca.ibm.com>: > Thanks David and Michael for the clarification. > > I think I understand the rational behind those checks in delinearization > now. > > > Some other languages have stronger guarantees about their array > dimensions accesses being in range. But this being

Hi, Thanks for the input. In my ptr_test.O1.ll, the two loops should fall into the last case due to loop rotations. And I think we should handle that case. I propose to check the dominance relation between loop predecessor blocks of the two loops if there is no dominance relation between their loop headers just like case three. The only thing I'm not pretty sure is that is there guarantee to

Hi, Recently I got a crash when I tried to analysis a program with ScalarEvolution AliasAnalysis(SCEV-AA for short). It turns out to be a (possibly) incorrect assertion inside the CompareSCEVComplexity routine. The simplest solution would be just remove that assertion but I also found that the surrounding logics on calculating SCEV cost seems to be incorrect either. Thus I want to discuss with

A Proposal for adding an experimental IR-level region-annotation infrastructure ============================================================================= Hal Finkel (ANL) and Xinmin Tian (Intel) This is a proposal for adding an experimental infrastructure to support annotating regions in LLVM IR, making use of intrinsics and metadata, and a generic analysis to allow transformations to

Hi All, Just a quick update on the Motorola 6800 backend: Based on the feedback, "M68k" (with lowercase "k") will now be the canonical target name and "m68k" be the target triple name. I've updated all the patches under review to reflect this change. I'm also asking for everyone's help to review all the patches. /* Target independent changes */ 1.

We would like to propose a new feature to disable optimizations on IR Functions that are considered “cold” by PGO profiles. The primary goal for this work is to improve code optimization speed (which also improves compilation and LTO speed) without making too much impact on target code performance. The mechanism is pretty simple: In the second phase (i.e. optimization phase) of PGO, we would add