similar to: Hoisting in the presence of volatile loads.

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 12/20/2017 1:37 PM, Sanjoy Das wrote:> > Fwiw, I was under the impression that regular loads could *not* be > reordered with volatile loads since we could have e.g.: > > int *normal = &global_variable; > volatile int* ptr = 0; > int k = *ptr; // segfaults, and the signal handler writes to *normal > int value = *normal; > > and that we'd have

Daniel, Thanks a lot for the pointer, that's very helpful! I'll use that as a guide to update how we handle volatile accesses. Mind if I ask for feedback when I update the patch? Krzysztof, Thanks for the answer, that was very informative! I appreciate it! Best, Alina On Wed, Dec 20, 2017 at 5:33 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > Hi Alina, > The

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

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

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

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,

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

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

Hi all, >> I think that this is the right way to approach this: we should change >> MemorySSA to be less conservative in this regard. LLVM's language reference is >> pretty explicit about reordering volatile and non-volatile operations: >> >>> The optimizers must not change the number of volatile operations or change >>> their order of execution

(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

For doing PRE on the load, it looks like there’s only two things stopping GVN PRE from doing it: * GVN::PerformLoadPRE doesn’t hoist loads that are conditional. Probably this can be overcome with some kind of heuristic that allows it to happen in loops when the blocks where a load would have to be inserted are outside the loop. * IsFullyAvailableInBlock goes around the loop and

> On Feb 29, 2016, at 10:50 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Alina Sbirlea" <alina.sbirlea at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, February 29, 2016 7:06:51 PM > Subject: Re: [llvm-dev] RFC:

Sent from my iPhone > On Feb 29, 2016, at 3:39 PM, Alina Sbirlea <alina.sbirlea at gmail.com> wrote: > > > >> On Mon, Feb 29, 2016 at 2:06 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >>> On Feb 29, 2016, at 1:50 PM, Alina Sbirlea <alina.sbirlea at gmail.com> wrote: >>> >>> >>> >>> On Mon, Feb

----- Original Message ----- > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Alina Sbirlea" <alina.sbirlea at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, February 29, 2016 7:06:51 PM > Subject: Re: [llvm-dev] RFC: Add bitcode tests to test-suite > Sent from my iPhone > On Feb