similar to: [LLVMdev] Optimization hints for "constant" loads

On 09/28/2014 01:22 AM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Philip Reames" <listmail at philipreames.com> >> To: llvmdev at cs.uiuc.edu >> Cc: "Hal Finkel" <hfinkel at anl.gov>, nicholas at mxc.ca >> Sent: Wednesday, September 10, 2014 12:11:28 AM >> Subject: Optimization hints for "constant" loads

> On Dec 1, 2014, at 3:44 PM, Philip Reames <listmail at philipreames.com> wrote: > > (Spawning a separate subthread off the 'Optimization hints for "constant" loads' discussion for a related question. ) > > Looking at TBAA again, I was reminded that TBAA also contains a third field which indicates that "meaning pointsToConstantMemory should return

Hi, This is Ariel from the Rust team again. I am having another pass ordering issue. Looking at the pass manager at https://github.com/llvm-mirror/llvm/blob/7034870f30320d6fbc74effff539d946018cd00a/lib/Transforms/IPO/PassManagerBuilder.cpp (the early SimplifyCfg now doesn't sink stores anymore! I can't wait until I can get to use that in rustc!) I find that the loop optimization group

Hi, I met an alias analysis problem in the LICM phase. I am using the following piece of code to present this problem. 1 int size; 2 int ** AAA; 3 void * xalloc(int); 4 5 void foo(void) 6 { 7 int i; 8 AAA = (int**) xalloc(size * sizeof(int*)); 9 10 for (i=0; i<size; i++) 11 AAA[i] = 0; 12 } This code tries to

On Fri, Oct 29, 2010 at 12:26 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > Xinliang David Li wrote: > >> As simple as >> >> void foo (int n, double *p, int *q) >> { >> for (int i = 0; i < n; i++) >> *p += *q; >> } >> >> clang -O2 -fstrict-aliasing -emit-llvm -o foo.bc -c foo.c >> llc -enable-tbaa -O2

Hi, On Wed, Jul 26, 2017 at 10:10 AM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > No, I mean in terms of enabling other optimizations in the pipeline like > vectorizer. Outliner does not expose any of that. I have not made a lot of effort to understand the full discussion here (so what I say below may be off-base), but I think there are some cases where

I think it would make sense for (1) and (2). I am not sure if (3) is feasible in instcombine. (I am not too familiar with LoopInfo) For the Octasic's Opus platform, I modified shouldMergeGEPs in our fork to: if (GEP.hasAllZeroIndices() && !Src.hasAllZeroIndices() && !Src.hasOneUse()) return false; return Src.hasAllConstantIndices(); // was return false;

On Fri, Mar 31, 2017 at 10:23 AM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Piotr, > > On March 31, 2017 at 9:07:42 AM, Piotr Padlewski > (piotr.padlewski at gmail.com) wrote: > > 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 >

On 01/07/2015 05:33 PM, Chandler Carruth wrote: > How does this compare with classical approaches of loop peeling, > partitioning, fission, or whatever you might call it? I'm still developing a good sense for this, but let me lay out some observations. Fair warning, this is going to be long and rambling. Let's start with a toy example: while(c) { x = this->x; y =

Our frontend can guarantee that loads from globals are rematerializable and do not alias with any stores in any function in the given module. We'd like the optimization passes (and ideally the register allocator as well) to be able to use this fact. The globals are not constant "forever" but are constant during the calling of any given function in the module. There seem to

> On Aug 15, 2018, at 10:57 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 08/15/2018 02:38 PM, Philip Reames via llvm-dev wrote: >> I'm concerned that we're focusing on one side of this. Let me point out a few concerns w/changing the canonical form here: >> >> LICM does not know how to hoist or sink regions. It does know

Xinliang David Li wrote: > > > On Fri, Oct 29, 2010 at 12:26 AM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca>> wrote: > > Xinliang David Li wrote: > > As simple as > > void foo (int n, double *p, int *q) > { > for (int i = 0; i < n; i++) > *p += *q; > } > >

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 literatures, there are even more > algorithm to consider for doing pointer analysis. > > > For at least some published AA algorithms, there may be some > uncertainty about software patents

Hi, On Wed, Jul 26, 2017 at 12:54 PM, Sean Silva <chisophugis at gmail.com> wrote: > The way I interpret Quentin's statement is something like: > > - Inlining turns an interprocedural problem into an intraprocedural problem > - Outlining turns an intraprocedural problem into an interprocedural problem > > Insofar as our intraprocedural analyses and transformations are

Since introducing the new TargetTransformInfo analysis, there has been some confusion over the role of target heuristics in IR passes. A few patches have led to interesting discussions. To centralize the discussion, until we get some documentation and better APIs in place, let me throw out an oversimplified Straw Man for a new pass pipline. It serves two purposes: (1) an overdue reorganization of

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

Hello, We've run across the following missed optimization: in the attached loop (addind.c/addind-opt.ll) there's a lookup into an array (V) using an indirect index (coming from another array, WI[k]) offset by a loop- invariant base (l). The full addressing expression can be reassociated so that we add the offset l to V's base first, and then add the indirect part. This makes

Hi Mark, It is not clear to me at all that preventing the merging is the right solution. There are a large number of analysis, including alias analysis, and optimizations that use GetUnderlyingObject, and related routines to search back through GEPs. They only do this up to some small finite depth (six, IIRC). So reducing the GEP depth is likely the right solution for InstCombine (which has the

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

Hi, I'm trying to optimize a simple C code and came across a situation where invariant code is not being moved out: On an -O3 compilation, I noticed that the "load" for the loop bounds (which remain invariant throughout) happens on each iteration of both the loops, even though it is not modified anywhere in the function "bigLoop". It seems that alias analysis is not able