search for: intraprocedural

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 strictly > more powerful than interprocedural, then there is a precise sense in which > inlining exposes optimization opportuniti...

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

...gt; for anything in the function (because its big and reads and writes > everything), we'll still have to constrain our transformations just > because we *might* later deduce a function attribute that triggers > these kinds of bugs. > > Essentially, you're proposing to limit intraprocedural optimization > to when we can successfully to interprocedural optimization > ("privatization"), where I'm suggesting we limit interprocedural > optimization to leave intraprocedural optimization unconstrained. > Given the ratio of our optimizations (almost all are intra, v...

...function (because its big and reads and writes > > everything), we'll still have to constrain our transformations just > > because we *might* later deduce a function attribute that triggers > > these kinds of bugs. > > > > Essentially, you're proposing to limit intraprocedural optimization > > to when we can successfully to interprocedural optimization > > ("privatization"), where I'm suggesting we limit interprocedural > > optimization to leave intraprocedural optimization unconstrained. > > Given the ratio of our optimizations (alm...

...t; wrote: > Hi, > > On Wed, Jul 26, 2017 at 12:54 PM, Sean Silva <chisophugis at gmail.com <mailto: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 strictly > > more powerful than interprocedural, then there is a precise sense in which > > inlining exposes...

...39;ll still have to constrain our transformations > > > just > > > > because we *might* later deduce a function attribute that > > > triggers > > > > these kinds of bugs. > > > > > > > > Essentially, you're proposing to limit intraprocedural > > > optimization > > > > to when we can successfully to interprocedural optimization > > > > ("privatization"), where I'm suggesting we limit interprocedural > > > > optimization to leave intraprocedural optimization unconstrained. &gt...

...o deduce function attributes for anything in the function (because its big and reads and writes everything), we'll still have to constrain our transformations just because we *might* later deduce a function attribute that triggers these kinds of bugs. Essentially, you're proposing to limit intraprocedural optimization to when we can successfully to interprocedural optimization ("privatization"), where I'm suggesting we limit interprocedural optimization to leave intraprocedural optimization unconstrained. Given the ratio of our optimizations (almost all are intra, very few are inter),...

...g> wrote: > >> 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 strictly >> > more powerful than interprocedural, then there is a precise sense i...

...lly important separation of concerns as it ensures that we don't get an explosion of different analyses supporting various different subsets of profile sources. Now, the original design only accounted for profile information *within* a function body, clearly it needs to be extended to support intraprocedural information. But I would still expect that to follow a similar layering where we first read the data into IR annotations, then have an analysis pass (this time a module analysis pass in all likelihood) that brokers access to these annotations through an API that can do intelligent things like synth...

...lvm-dev at lists.llvm.org>> wrote: Hi, On Wed, Jul 26, 2017 at 12:54 PM, Sean Silva <chisophugis at gmail.com<mailto: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 strictly > more powerful than interprocedural, then there is a precise sense in which > inlining exposes optimization opportuniti...

...>>>> 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 >>>> strictly >>>> > mo...

...s big and reads and writes >> > everything), we'll still have to constrain our transformations just >> > because we *might* later deduce a function attribute that triggers >> > these kinds of bugs. >> > >> > Essentially, you're proposing to limit intraprocedural optimization >> > to when we can successfully to interprocedural optimization >> > ("privatization"), where I'm suggesting we limit interprocedural >> > optimization to leave intraprocedural optimization unconstrained. >> > Given the ratio of our op...

...e a function attribute that > > > > > triggers > > > > > > > > > > > these kinds of bugs. > > > > > > > > > > > > > > > > > > > > > > Essentially, you're proposing to limit intraprocedural > > > > > optimization > > > > > > > > > > > to when we can successfully to interprocedural optimization > > > > > > > > > > > ("privatization"), where I'm suggesting we limit > > > > &g...

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 in general does not extend to IPA >>> (we will reopen discussion on that soon), but profile summary is >>> 'invariant'/readonly data, which should be available to IPA...

...order to *set* or *update* the profile information without doing detailed analysis on it. Which seems fine with my outline of the invariants? > >> 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 in general does not extend to IPA > (we will reopen discussion on that soon), but profile summary is > 'invariant'/readonly data, which should be available to IPA already. > I don't know what y...

...gorithm for propagating constraints (inequalities) on variables is interprocedural (good) and inefficient (bad). ABCD has different tradeoffs. IIRC, ABCD doesn't use an external solver, though only because it only handles simple sets of inequalities. The original ABCD algorithm is also intraprocedural, which seems extremely limiting in practice. Is there any plan of extending this to work interprocedurally? --Vikram Associate Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve

...: #include <stdio.h> void f1(int a) { a=a+1; printf("%d",a); } void f2() { int b; b=1; f1(b); } int main() { int a=1; f2(); f1(a); } Also,when i use the following command: opt -print-after-all main.bc The dumps generated dont include IPCP or Intraprocedural Const Propagation dumps.Why so? Is there any other way to see the effect of a pass on the i/p bitcode file? Kindly let me know where i am going wrong. Netra, >> ---------------------------- Original Message ---------------------------- >> Subject: Regarding Inter Procedural Constant...

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

...proximations. See, e.g, http://dl.acm.org/citation.cfm?doid=161494.161501 and http://dl.acm.org/citation.cfm?id=186025.186041 (btw, it gets worse. If you disallow recursive data structures, and allow multiple levels of pointers, precise flow-sensitive may-alias is NP-hard even when restricted to intraprocedural and *no* dynamic memory allocation) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170312/eb9b389a/attachment.html>

...ted 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 [1994] paper and provides a branch predictor that calculates probabilities. The implementation also covers an intraprocedural and interprocedural frequency calculator for edges and functions. Reference: Youfeng Wu and James R. Larus. Static branch frequency and program profile analysis. In MICRO 27: Proceedings of the 27th annual international symposium on Microarchitecture. IEEE, 1994. Regards, Andrei On Tue,...