search for: intraprocedurally

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

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

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Sanjoy Das" <sanjoy at playingwithpointers.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" <listmail at philipreames.com>, "Duncan P. N. Exon Smith" >

On Fri, Feb 26, 2016 at 7:26 PM Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Chandler Carruth" <chandlerc at google.com> > > To: "Hal Finkel" <hfinkel at anl.gov>, "Sanjoy Das" < > sanjoy at playingwithpointers.com> > > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>,

Apologies for delayed joining of this discussion, but I had a few notes from this thread that I really wanted to chime in about. River, I don't mean to put you on the spot, but I do want to start on a semantic issue. In several places in the thread you used the words "we" and "our" to imply that you're not alone in writing this (which is totally fine), but your

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" > <listmail at philipreames.com>, "Duncan P. N. Exon Smith" > <dexonsmith at apple.com>, "Xinliang David Li"

I think this will have a much higher cost than my proposal to constrain how we deduce function attributes (which still fixes Sanjoy's latest example). Specifically, I think this will force us to constrain far too many transformations for the sake of code size in functions that we won't inline. Even if we were never going to deduce function attributes for anything in the function (because

2017-07-28 21:58 GMT-07:00 Chris Bieneman via llvm-dev < llvm-dev at lists.llvm.org>: > Apologies for delayed joining of this discussion, but I had a few notes > from this thread that I really wanted to chime in about. > > River, > > I don't mean to put you on the spot, but I do want to start on a semantic > issue. In several places in the thread you used the words

On Mon, Apr 18, 2016 at 2:48 PM Hal Finkel <hfinkel at anl.gov> wrote: > > > ------------------------------ > > *From: *"Xinliang David Li" <davidxl at google.com> > > On Mon, Apr 18, 2016 at 2:33 PM, Mehdi Amini <mehdi.amini at apple.com> > wrote: >> >> In the current case at stake: the issue is that we can't make the >>

Hi Chris, > One particular disagreement that I think very much needs to be revisited in this thread was Jessica's proposal of a pipeline of: > 1. IR outline > 2. Inline > 3. MIR outline IMHO, there is no need to restrict a place of the Outliner in the pipeline at the moment. I hope people representing different architectures will try different configurations and the best will be

...and adding $0.02 to the "IR outline + inline + MIR outline" idea, my gut feeling (yes, only a "feeling" -- and one coming from my gut, not head!) is that inlining correcting wrong IR outlining decisions with MIR outlining correcting wrong inlining decisions is absolutely unrealistic and a heuristics nightmare at best. Inliner's heuristics are already complex enough and

On Fri, Feb 26, 2016 at 7:38 PM Hal Finkel <hfinkel at anl.gov> wrote: > *From: *"Chandler Carruth" <chandlerc at google.com> > *To: *"Hal Finkel" <hfinkel at anl.gov> > > *Cc: *"llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" < > listmail at philipreames.com>, "Duncan P. N. Exon Smith" <

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" > <listmail at philipreames.com>, "Duncan P. N. Exon Smith" > <dexonsmith at apple.com>, "Xinliang David Li"

On Mon, Apr 18, 2016 at 4:38 PM Xinliang David Li <davidxl at google.com> wrote: > >>>> Now, the original design only accounted for profile information >>>> *within* a function body, clearly it needs to be extended to support >>>> intraprocedural information. >>>> >>> >>> >>> Not sure what you mean. Profile data

On Mon, Apr 18, 2016 at 3:45 PM Xinliang David Li <davidxl at google.com> wrote: > On Mon, Apr 18, 2016 at 3:00 PM, Chandler Carruth <chandlerc at gmail.com> > wrote: > >> On Mon, Apr 18, 2016 at 2:48 PM Hal Finkel <hfinkel at anl.gov> wrote: >> >>> >>> >>> ------------------------------ >>> >>> *From:

On Jun 5, 2009, at 9:26 AM, Mai, Haohui wrote: > By static array bounds checking, I mean eliminating array bounds > checking > which can be proved ``safe'' at compile-time. Even though SAFECode does have such a pass, there are some tradeoffs with the current version: 1. It uses an external solver (Omega), which is one more dependence for LLVM in general. I don't have

Hi, I used the following commands on the program attached below: llvm-gcc --emit-llvm main.c -c -o main.bc opt -ipconstprop main.bc -o main1.bc diff main.bc main1.bc no difference was o/p :( The Program Segment is as shown below: #include <stdio.h> void f1(int a) { a=a+1; printf("%d",a); } void f2() { int b; b=1; f1(b); } int main() { int

Hi all... I am developing a program slicing framework using LLVM. The idea is to remove the computation parts from the program and only keep the parts relevant for the control flow. For example, in the following C loop. for (i=0;i<=VAL;) { printf("In the loop"); a=b+c; b=h+k; i++; printf("%d",i); } after slicing... for (i=0;i<=VAL;) { i++;

On Sun, Mar 12, 2017 at 2:55 PM, Oliver Braunsdorf via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Perhaps by "value" you mean points-to set? > > Thats right! I meant the points-to set. Sorry I didn't mention that. > I want to track back the value of the parameter to its definition -- an > "assignment" which could be indirect through a pointer

Hello Kapil, I have implemented a static profiler for LLVM as a google summer of code project in 2009. I wrote it for the 2.4 branch, but the implementation never made into the tree. I have recently ported it to LLVM 2.8, but I haven't tested it. You can take a look at the code from: http://homepages.dcc.ufmg.br/~rimsa/tools/stprof-llvm.patch The implementation is based on Wu's