similar to: [LLVMdev] alias set collapse and LICM

Hi All, I'm looking into converting LICM to use MemorySSA instead of AliasSets to determine when it is safe to hoist/sink/promote loads and stores to get around the issue of alias set collapse (see discussion [1]). I have a prototype implementation, but have run into two issues that I could use input from the designers of MemorySSA to resolve: 1) Is MemorySSA intended to be

On 06/12/2015 04:14 PM, Andrew Trick wrote: >> On Jun 12, 2015, at 2:52 PM, Philip Reames <listmail at philipreames.com> wrote: >> >> >> >> On 06/12/2015 02:10 PM, Andrew Trick wrote: >>>> On Jun 12, 2015, at 2:06 PM, Daniel Berlin <dberlin at dberlin.org> wrote: >>>> >>>> On Fri, Jun 12, 2015 at 2:03 PM, Andrew Trick

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

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

> Can you explain why the alias sets are collapsed into one here? If I'm reading the code correctly, it is because the readonly call aliases all of %a, %b and %c. Since two pointers can be in two different alias sets only if they do not alias, %a has to be in the same alias set as the read only call and so does %b and %c. Therefore, all of them have to be in the same alias set. > Can

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

So, you can't have disjoint sets, and have one of set that says "i access everything". Because it would contain everything :) Thus, I assume by your description you meant "we want to maintain multiple disjoint partitions of the same set of accesses" (which is not quite the same as just having one special partition). When one partition is a refinement of the other (as

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

Hi Daniel, Thanks for the info. I’ve started looking into converting EarlyCSE to use MemorySSA first since 1) I don’t think it needs any additional MemorySSA update API and 2) the particular case I’m looking at needs EarlyCSE to catch more load cases before LICM to be profitable. I have a prototype working, but have run into two issues: 1) readonly calls are treated as clobbers by

On Fri, Jun 12, 2015 at 2:03 PM, Andrew Trick <atrick at apple.com> wrote: > > On Jun 12, 2015, at 1:51 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > So, you can't have disjoint sets, and have one of set that says "i > access everything". Because it would contain everything :) > > Thus, I assume by your description you meant "we want to

On Mon, Apr 27, 2015 at 4:21 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > You can't win here (believe me, i've tried, and better people than me have > tried, for years :P). > No matter what you do, the partitioning will never be 100% precise. The > only way to solve that in general is to pairwise query over the > partitioning. > > Your basic problem is

On Mon, Mar 21, 2016 at 6:28 PM, Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 03/21/2016 08:56 AM, Jia Chen via llvm-dev wrote: > > Hi Christian, > > Thank you so much for the reply! Please see my comments inline. > > On 03/21/2016 09:32 AM, Christian Convey wrote: > > Hi Jia, > > If one looks at existing research

On 06/12/2015 02:10 PM, Andrew Trick wrote: >> On Jun 12, 2015, at 2:06 PM, Daniel Berlin <dberlin at dberlin.org> wrote: >> >> On Fri, Jun 12, 2015 at 2:03 PM, Andrew Trick <atrick at apple.com> wrote: >>> On Jun 12, 2015, at 1:51 PM, Daniel Berlin <dberlin at dberlin.org> wrote: >>> >>> So, you can't have disjoint sets, and have

----- Original Message ----- > From: "Ashutosh Nema" <Ashutosh.Nema at amd.com> > To: "songlh" <songlh at cs.wisc.edu>, llvmdev at cs.uiuc.edu > Sent: Wednesday, February 11, 2015 3:20:27 AM > Subject: Re: [LLVMdev] question about licm > > Hi, > > LICM can only hoist instructions which dominates all loop exit > blocks. > In this case

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

hi, I applied licm with basicaa on the following codes: int j = atoi(argc[1]); int lower[] = {10, 9, 8, 7, 6, 5, 4, 3, 2, 1}; int upper[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; for(i = lower[j]; a[i] < 100 && i < upper[j]; i ++); I notice that upper[j] is not hoisted out from the loop. Is this because j could be larger than 10? Thanks a lot! Best,

Hi all, I have a question about dereferenceable metadata on load instruction. I have a patch (https://reviews.llvm.org/D31539) for LICM that hoists loads with !invariant.group. The motivation example is devirtualization: struct A { virtual void foo(); }; int bar(); void indirect(A &a) { while(bar()) a.foo(); } With -O2 -fstrict-vtable-pointers we get: define void

2017-04-01 15:59 GMT+02:00 Piotr Padlewski <piotr.padlewski at gmail.com>: > > > 2017-03-31 23:20 GMT+02:00 Sanjoy Das <sanjoy at playingwithpointers.com>: > >> Hi Piotr, >> >> On March 31, 2017 at 1:07:12 PM, Piotr Padlewski >> (piotr.padlewski at gmail.com) wrote: >> > [snip] >> > Do I understand it correctly, that it is legal to

On 03/21/2016 06:53 PM, Daniel Berlin wrote: > > > On Mon, Mar 21, 2016 at 6:28 PM, Philip Reames via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > On 03/21/2016 08:56 AM, Jia Chen via llvm-dev wrote: >> >> >> I did some preliminary experiments with licm on c programs over >> the