similar to: MemorySSA LLVM-dev meeting notes and upcoming meetings

Hi all, Thank you to all who responded to the planning poll. The meeting is set for 10:30 Pacific Time/5:30pm UTC (in about 3h). Details in the google doc <https://docs.google.com/document/d/1-uEEZfmRdPThZlctOq9eXlmUaSSAAi8oKxhrPY_lpjk/edit#> included before. The agenda includes progress on the topics discussed last time (meeting notes in the doc), and open discussions and questions from

Hi Hal, Yes, the "internal" caches AA would be valid as long as the IR is not mutated. Are you suggesting keeping them? It's possible, but it will be very tricky to ensure they are cleared at the right times and they will likely be prone to adding hidden bugs. I don't have strong indications currently that keeping such information would be useful by other users, other than

Great, thanks! Are you planning on just talking about these things with slides? Do we have other things to which we can link for people to read? -Hal Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ________________________________ From: Tarique Islam <tislam at ca.ibm.com> Sent: Thursday, May 21, 2020 8:19:31 AM To:

Hi all, After a long ride, I'm planning to turn on the use of MemorySSA for loop passes (D58311 <https://reviews.llvm.org/D58311>) tomorrow (8/29). Please let me know if you have issues, concerns or feedback on this. Best, Alina -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 2/10/20 2:35 PM, Alina Sbirlea wrote: > Hi, > > Here's a tentative patch of the changes for this: D74353 > <https://reviews.llvm.org/D74353>. I suppose that, as expected, it's invalidated less often this way. Given that it's generally stateless, does this really represent a cost savings?  -Hal > > Thank you, > Alina > > > On Mon, Feb 10,

To join our call on Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC please use this information: Meeting URL https://bluejeans.com/643493129?src=join_info Meeting ID 643 493 129 Want to dial in from a phone? Dial one of the following numbers: +1.312.216.0325 (US (Chicago)) +1.408.740.7256 (US (San Jose)) +1.866.226.4650 (US Toll Free) (see all numbers -

Hi, everyone, We had a great call last month, and progress is definitely being made on several fronts. The notes from our last call are available here: https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit#heading=h.vpxs8lkuxy79 and, also, pasted below. DOODLE POLL: As we discussed on our last call, I would like to schedule a regular call to discuss

Hi, everyone, A quick reminder: This call will start in approximately four hours. See below for how to join. On our current agenda: Agenda * Full restrict patch * Observation and clarification * Issues encountered * Speed up in intersection code - O(nlog(n)) * Calling Verifier after LoopVectorize pass? -Hal Hal Finkel Lead, Compiler Technology and Programming

Hi, I wanted to give a heads-up that I've been looking into replacing the AliasSetTracker(AST) with MemorySSA in the Loop Invariant Code Motion (LICM) pass. I would love to get feedback on the best way to incrementally push in this change. Motivation: There has been an outstanding issue with using the Alias Set Tracker due to its expensive construction time (quadratic). We've had test

Hi Krzysztof, Could I get some background info on reasoning about hoisting in the presence of volatile loads? I was looking at this testcase: test/Transforms/LICM/volatile-alias.ll Context: MemorySSA treats volatile loads as defs. I'm looking to better understand expected behavior in the presence of volatile accesses. More context: https://reviews.llvm.org/D40375. Thanks in advance, Alina

Hi Florian, Following up on D86967, I missed that all the timings were using the legacy pass manager. Did you do any testing on the compile and run time impact for the new pass manager? Thank you, Alina On Tue, Aug 25, 2020 at 12:51 PM Florian Hahn <florian_hahn at apple.com> wrote: > Hi, > > Thanks for all the responses! > > My understanding is that there were no

Yes, this is odd. On my clang.bc Without: 2.2967 ( 53.8%) 0.0242 ( 26.4%) 2.3210 ( 53.2%) 2.3227 ( 53.2%) Memory SSA 2.3364 ( 53.7%) 0.0246 ( 25.7%) 2.3610 ( 53.1%) 2.3636 ( 53.1%) Memory SSA 2.3353 ( 54.0%) 0.0258 ( 27.0%) 2.3611 ( 53.4%) 2.3632 ( 53.3%) Memory SSA With two getModRefInfo calls: 3.0302 ( 58.8%) 0.0328 ( 29.9%) 3.0630 ( 58.2%) 3.0858 ( 58.2%)

Hi Florian, First, thank you for working on this. I'm really glad to see this work so close to being enabled. I think the numbers look good for run time, and the benefits of switching for all configurations are clear. For compile time, the current regressions are noticeable, but not a deal breaker in my opinion. I'm very much in favor of switching in all configurations. To address some

On Mon, Oct 9, 2017 at 1:57 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > FWIW: Bootstrap is probably not a good test of this, there are bugs filed > where we end up with tons of loads and stores to test against each other. > That's actually fairly rare in bootstrap, as you can see. > Let me get you some test cases. > SG, thanks! > > My guess is that we

Hi, everyone, We've had a number of discussions recently, including on the Flang technical call, about potential improvements to LLVM's alias analysis to support handling restrict and restrict-like semantics. We would like to try having a call to discuss these issues further. Please, if you're interested in joining, indicate your availability (prior to the end of this week):

TL;DR: I'm looking to have AliasAnalysis passes have the ability keep a temporary cache when no transformations are performed. I'm interested to first and foremost clarify what is the best way to even start such an infrastructure change, such that it is not abused (or even available) by other passes. We certainly don't want to keep arbitrary caches in all passes. Would making this a

On 12/20/2017 03:49 PM, Alina Sbirlea via llvm-dev wrote: > +Philip to get his input too. > I've talked with George offline, and here's a summary: > > In D16875 <https://reviews.llvm.org/D16875>, the decision made was: > "The LLVM spec is ambiguous about whether we can hoist a non-volatile > load above a volatile load when the loads alias. It's probably

On Fri, Sep 14, 2018 at 4:25 PM Philip Reames <listmail at philipreames.com> wrote: > This is going OT from the original thread, but, what the heck... > Sorry, not my intention, I was just giving another reason why getting promotion done in LICM differently would be helpful. > Alina, can you explain the challenge with implementing promotion over > MemorySSA? On the surface, it

(minor inline additions) On 09/13/2018 01:51 AM, Chandler Carruth wrote: > Haven't had time to dig into this, but wanted to add +Alina Sbirlea > <mailto:asbirlea at google.com> to the thread as she has been working on > promotion and other aspects of LICM for a long time here. Thanks! > On Wed, Sep 12, 2018 at 11:41 PM Philip Reames > <listmail at philipreames.com

Michael makes a great point about aliasing here and different indexing that accesses the same element! Another note: x = A[0][2] is fundamentally different depending on the type of `A`. If e.g. A was declared: int A[10][20], there's only _one_ load. A is a (and is treated as) a linear buffer, and GEPs only pinpoint the specific position of A[0][2] in this buffer (i.e. 0*10 + 2). But if A was