similar to: Loop Opt WG Meeting Agenda for July 15, 2020

Hi, I've been wondering why LLVMs GEP instructions are based on types, rather than encoding the raw address calculation as a base pointer plus some scaled offsets (still in the form of a GEP, to retain provenance). The type information does not seem particularly useful (shouldn't be used as an optimization base, because struct layouts lie), but increases the non-canonical IR space (there

On Sun, Apr 5, 2020 at 6:34 PM Stefanos Baziotis < stefanos.baziotis at gmail.com> wrote: > Hi Craig, > > > Adding a nuw to the add -8 is incorrect. > Yeah, I didn't mean to say it was correct. It was just an observation that > with nuw the optimization was happened and I asked if someone thought it > was somehow connected. > > > From the perspective of the

Adding a nuw to the add -8 is incorrect. From the perspective of the unsigned math, -8 is treated a very large positive number. The input to the add is [8,13) and adding a large positive number to it wraps around past 0. So that is guaranteed unsigned wrap. On the other hand, a sub nuw 8 would be correct. ~Craig On Sun, Apr 5, 2020 at 3:27 PM Stefanos Baziotis via llvm-dev < llvm-dev at

Hi Michael, Thanks for the reply. I've seen but have not used it. FWIW, the problem is not how to generate the runtime checks (although it'd be good if we can get it for free), but how to clean up the SCEVs. Does PSE do that ? Cheers, Stefanos Στις Δευ, 21 Σεπ 2020 στις 11:59 π.μ., ο/η Michael Kruse < llvmdev at meinersbur.de> έγραψε: > Have you looked into

Hello, Following up on last week's LLVM-Dev meeting where we discussed MemorySSA related topics, I created the following google doc <https://docs.google.com/document/d/1-uEEZfmRdPThZlctOq9eXlmUaSSAAi8oKxhrPY_lpjk/edit#> with some of the meeting notes and planning for future meetings. For those who participated, please feel free to add items I may have missed into the document and cc

Hey, I am Swapnil Raj I am student in Trinity College Dublin and I am interested in working on LLVM. I am really interested in two projects listed, the first one is the extending the clang AST with template information and the second is finding smart null pointer dereferences. I am passionate about compilers and interpreters, I have written a few small language based on lambda calculus. I am

> On Apr 5, 2020, at 22:20, Stefanos Baziotis <stefanos.baziotis at gmail.com> wrote: > > > Any idea about how the compiler could remove the lshr and use a add -16? > Actually, I just figured that doing this test is like solving this: > > 8 <= x/2 <= 13 > 16 <= x <= 26 > 0 <= x - 16 <= 10 => 0 <= x < 11 > The left part is know since

Stefanos Baziotis via llvm-dev <llvm-dev at lists.llvm.org> writes: > Well... I tried that and it doesn't seem to be very useful > unfortunately. The C/C++ way that arrays are defined is probably why > DA is not that useful. Namely that a row can alias with another row in > 2D arrays. The theory behind DA is quite powerful if we knew that they > don't alias. Right

Indeed you're right, thanks! I need a nuw (which I have to invent, with a run-time check, since it doesn't exist in the original but anyway). Best, Stefanos Στις Παρ, 31 Ιουλ 2020 στις 12:36 μ.μ., ο/η Florian Hahn < florian_hahn at apple.com> έγραψε: > > > > On Jul 30, 2020, at 21:03, Stefanos Baziotis via llvm-dev < > llvm-dev at lists.llvm.org> wrote: >

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

Hi, > I think the IR in both of your examples makes things harder for the compiler than expected from the original C source. Note that both versions are from clang with -O2. The first is with version 9.0 and the second is with the trunk. > but in the branch only %0 is used. Sinking the lshr too early made the analysis harder. Yes, exactly! That's what I figured too. > The version

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

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 Stefanos, Thanks for your comments. I added both as reviewer. > One question though. Are you sure that this: > This helps with LICM when instructions inside a conditional is loop invariant  > is not achieved with the current LoopRotate pass? Because AFAIK, it does. Basically it inserts > a guard (that branches to the preheader) and then passes like LICM hoist invariant

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

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:

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 +

Now that I can build LLVM on Windows, I tried doing it. -------------------------- ... some good stuff ... C:/LLVM/llvm-project/llvm/lib/Support/Chrono.cpp:35:17: error: '::localtime_s' has not been declared; did you mean 'localtime'? 35 | int Error = ::localtime_s(&Storage, &OurTime); | ^~~~~~~~~~~ | localtime (The error