similar to: RFC: Contained stateful AliasAnalysis

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

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

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

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

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

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

(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

> On Aug 18, 2020, at 16:59, Michael Kruse <llvmdev at meinersbur.de> wrote: > > Thanks for all the work. The reductions in stores look promising. Do you also have performance numbers how much this improves the execution time? Did you observe any regressions where MSSA resulted in fewer removed stores? I did not gather numbers for execution time yet, but I’ll try to share some

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

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

I'm trying to understand what is the result we'd seek in the example in D38569 (pasting here for quick access) double f(double a) { double b; double c,d; double (*fp) (double) __attribute__ ((const)); /* Partially redundant call */ if (a < 2.0) { fp = sin; c = fp (a); } else { c = 1.0; fp = cos; } d = fp (a);

Hi, I'd like to understand if it makes sense to keep BasicAA as a not CFG-only pass, or if it can be updated to CFG-only. The change was made in D44564 <https://reviews.llvm.org/D44564>. >From what I gathered the motivation was PhiValuesAnalysis not being properly updated, and BasicAA having an instance of it. PhiValuesAnalysis now uses callback values to invalidate deleted values (

Hi, I am performing meta-regression using linear mixed-effect model with the lme() function that has two fixed effect variables;one as a log transformed variable (x) and one as factor (y) variable, and two nested random intercept terms. I want to save the predicted values from that model and show the log curve in a plot ; predicted~log(x) mod<-lme(B~log(x)+as.factor(y),