similar to: Delinearization validity checks in DependenceAnalysis

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 +

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

[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 all, Apparently some people had trouble joining today. I also had trouble using the attendee ID provided by webex. I've canceled the meeting series and will be scheduling a new one with an updated link. Please remember to update your calendars with the new invite. My apologies to those who couldn't join today, and to everyone for the churn. Today's Meeting Minutes:

--------------------------- 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 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

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

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

> 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 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

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

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>

On Wed, Sep 19, 2018 at 4:58 AM Venkataramanan Kumar < venkataramanan.kumar.llvm at gmail.com> wrote: > Hi, > > I tired to see when this behavior changed in LLVM. > It seems to start from. > --snip-- > commit 95e5d37d5868ebde2302bc302c1e0af407c5646d > Author: Sebastian Pop <sebpop at gmail.com> > Date: Tue Mar 6 21:55:59 2018 +0000 > > DA: remove

LLVM friends, I'm currently trying to make LoopVectorizationLegality class in Transform/Vectorize/LoopVectorize.cpp more modular and eventually move it to Analysis directory tree. It uses several file scope helper functions that do not really belong to LoopVectorize. Let me start from getPointerOperand(). Within LLVM, there are five other similar functions defined. I think it's time to

Erkan, you're right. Sorry about that. Attached is the most recent version. Preston Hi Preston, > I am trying to use DA as well. I used your example and commands that you > wrote in order to get DA information. > However, it does not report any dependence info. > I am wondering whether your local copy differs from the one on the > repository ? > Thanks. > Erkan.

"Saito, Hideki via llvm-dev" <llvm-dev at lists.llvm.org> writes: > LLVM friends, > > I'm currently trying to make LoopVectorizationLegality class in > Transform/Vectorize/LoopVectorize.cpp more modular and eventually move > it to Analysis directory tree. It uses several file scope helper > functions that do not really belong to LoopVectorize. Let me start

Hi all, Unfortunately, all my Hunks are failed when I apply : patch -p1 < da.patch command. The problem might be due to the fact that da.patch file was created against revision 167549, but I am on revision 167719 (I believe the most recent one). I am not sure if this cause the problem ? But Preston may I ask you to generate the patch file against revison 167719 ? Thanks in advance. On

----- Original Message ----- > From: "Adam Nemet" <anemet at apple.com> > To: "Ramshankar Ramanarayanan" <Ramshankar.Ramanarayanan at amd.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Saturday, January 17, 2015 12:20:55 AM > Subject: Re: [LLVMdev] proof of concept for a loop fusion pass > > > On Jan 15, 2015, at 4:22 PM, Ramanarayanan,