similar to: [LLVMdev] How to use BlockFrequency in inter-procedural context?

Displaying 20 results from an estimated 4000 matches similar to: "[LLVMdev] How to use BlockFrequency in inter-procedural context?"

2014 Dec 27
2
[LLVMdev] How to use BlockFrequency in inter-procedural context?
David Is this true for static heuristics as well ? If the bb freqs are scaled wrt to the entry block freq and a) use such scaled freqs for the bb's that have calls b) propagate this info topologically over the call graph, how representative will be the info if one just wants to use in a comparative sense ? -Dibyendu Sent from my Windows Phone ________________________________ From: Xinliang
2015 Jun 04
2
[LLVMdev] Assert in BlockFrequency pass
Hi, we got the following assert: assert(!Working[0].isLoopHeader() && "entry block is a loop header"); [in BlockFrequencyInfoImpl<BT>::tryToComputeMassInFunction(), BlockFrequencyInfoImpl.h] on a Hexagon target - the entry block is a loop header. Has someone seen this assert on other targets? What would be a preferable way to fix it: - extend BlockFrequency pass to
2015 Jun 04
2
[LLVMdev] Assert in BlockFrequency pass
> On 2015-Jun-04, at 12:45, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2015-Jun-04, at 12:28, Ivan Baev <ibaev at codeaurora.org> wrote: >> >> Hi, we got the following assert: >> >> assert(!Working[0].isLoopHeader() && "entry block is a loop header"); >> >> [in
2014 Feb 02
5
[LLVMdev] [RFC] BlockFrequency is the wrong metric; we need a new one
Right now, all profile information is funneled through two analysis passes prior to any part of the optimizer using it. First, we have BranchProbabilityInfo, which provides a simple interface to the simplest form of profile information: local and relative branch probabilities. These merely express the likelihood of taking one of a mutually exclusive set of exit paths from a basic block. They are
2014 Mar 07
2
[LLVMdev] [RFC] BlockFrequency is the wrong metric; we need a new one
On Feb 4, 2014, at 4:36 PM, Andrew Trick <atrick at apple.com> wrote: > > On Feb 4, 2014, at 4:07 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> >> On Feb 3, 2014, at 12:13 AM, Andrew Trick <atrick at apple.com> wrote: >> >>> On Feb 2, 2014, at 6:55 PM, Chandler Carruth <chandlerc at gmail.com> wrote: >>>
2013 Jun 17
2
[LLVMdev] BlockFrequency spill weights
[Splitting this out from the original thread to reduce noise in it] On 17.06.2013, at 18:43, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 17, 2013, at 7:03 AM, Benjamin Kramer <benny.kra at gmail.com> wrote: > >> >> On 17.06.2013, at 15:56, Diego Novillo <dnovillo at google.com> wrote: >> >>> On 2013-06-15 16:39 ,
2015 Mar 24
2
[LLVMdev] RFC - Improvements to PGO profile support
> On Mar 24, 2015, at 12:08 PM, Xinliang David Li <davidxl at google.com> wrote: > > On Tue, Mar 24, 2015 at 10:54 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> >>> On Mar 24, 2015, at 10:53 AM, Diego Novillo <dnovillo at google.com> wrote: >>> >>> On Tue, Mar 24, 2015 at 1:48 PM, Bob Wilson <bob.wilson at apple.com> wrote:
2015 Jan 08
9
[LLVMdev] Separating loop nests based on profile information?
I've been playing with approaches to getting better optimization of loops which contain infrequently executed slow paths. I've gotten as far as throwing together a proof of concept implementation of a profile guided optimization to separate a single loop with multiple latches into a loop nest, but I want to get feedback from interested parties before investing much more effort. The
2014 Feb 03
2
[LLVMdev] [RFC] BlockFrequency is the wrong metric; we need a new one
On Feb 2, 2014, at 6:18 PM, Andrew Trick <atrick at apple.com> wrote: >> The result of such a system would produce weights for every block in the above CFG as '1.0', or equivalent to the entry block weight. This to me is a really useful metric -- it indicates that no block in the CFG is really more or less likely than any other. Only *biases* in a specific direction would
2015 Mar 26
2
[LLVMdev] RFC - Improvements to PGO profile support
> On Mar 24, 2015, at 3:22 PM, Xinliang David Li <davidxl at google.com> wrote: > > On Tue, Mar 24, 2015 at 2:47 PM, Bob Wilson <bob.wilson at apple.com <mailto:bob.wilson at apple.com>> wrote: >> >>> On Mar 24, 2015, at 12:08 PM, Xinliang David Li <davidxl at google.com> wrote: >>> >>> On Tue, Mar 24, 2015 at 10:54 AM, Bob
2015 May 07
3
[LLVMdev] RFC - Improvements to PGO profile support
Can you tell us if you're continuing to use the same approach as described in one of the LLVM meetings, i.e. instrument at the clang AST level? Also, do you generate GCOV files, some yaml, or is this a separate format? And finally in the meeting you had given how you assign counters to the blocks, an algorithm to minimize the number of insertions. Is that algorithm a well-known one or a
2015 May 07
2
[LLVMdev] RFC - Improvements to PGO profile support
On Thu, May 7, 2015 at 8:43 AM, Bob Wilson <bob.wilson at apple.com> wrote: > >> On May 7, 2015, at 12:55 AM, Hayden Livingston <halivingston at gmail.com> wrote: >> >> Can you tell us if you're continuing to use the same approach as >> described in one of the LLVM meetings, i.e. instrument at the clang >> AST level? > > Yes, that is the
2014 Feb 03
4
[LLVMdev] [RFC] BlockFrequency is the wrong metric; we need a new one
On Sun, Feb 2, 2014 at 6:18 PM, Andrew Trick <atrick at apple.com> wrote: > > On Feb 2, 2014, at 2:13 AM, Chandler Carruth <chandlerc at gmail.com> wrote: > > > Right now, all profile information is funneled through two analysis > passes prior to any part of the optimizer using it. > > > > First, we have BranchProbabilityInfo, which provides a simple
2016 Mar 23
0
Open Project : Inter-procedural Register Allocation [GSoC 2016]
Hi Vivek, [+CC Matthias, Quentin] Inter-procedural register allocation can be a big win, but my estimate is that it will be challenging to complete within one summer unless you're already familiar with LLVM's register allocator. I've CC'ed some people who can give you some more detailed information. -- Sanjoy On Tue, Feb 9, 2016 at 9:17 PM, vivek pandya via llvm-dev
2016 Feb 10
3
Open Project : Inter-procedural Register Allocation [GSoC 2016]
Hello Community, I would like to know status of the project and also importance of it. If the project is still open I would like to work on GSoC 2016 proposal for Inter-procedural Register Allocation, in that case please also suggest possible mentor or let me know if anyone is willing to be mentor for this. Sincerely, *Vivek Pandya* -------------- next part -------------- An HTML attachment was
2012 Oct 02
2
[LLVMdev] Inter-procedural program flow analysis
Is there any inter-procedural analysis that could tell me if some BasicBlock Y is guaranteed to execute based on my knowledge that BasicBlock X will execute? For example: extern int x; void foo() { } int main() { if (x) { foo(); } else { foo(); } } I want to be told that the entry block of foo is guaranteed to be
2012 Oct 02
0
[LLVMdev] Inter-procedural program flow analysis
Isn't this effectively the halting problem? Consider the case where block Y is the exit block of main() and block X is the entry block of main(). Jim On Oct 2, 2012, at 4:29 PM, Stephen Schiffli <sschiffli at gmail.com> wrote: > Is there any inter-procedural analysis that could tell me if some BasicBlock Y is guaranteed to execute based on my knowledge that BasicBlock X will
2012 Oct 03
0
[LLVMdev] Inter-procedural program flow analysis
Okay thanks for the info. The term program termination was probably a poor choice of words. I'm really just trying to build an inter-procedural BasicBlock graph, and then look for postdominance as Scott suggested. I'll go about making my own since it doesn't sound like there is one out there already. Thanks, -Stephen On Tue, Oct 2, 2012 at 5:06 PM, Scott Moore <sdmoore at
2012 Oct 03
2
[LLVMdev] Inter-procedural program flow analysis
I think you're looking for an inter-procedural post dominator analysis. I don't think there is one in LLVM already, but it should be relatively straightforward. This gives a sound approximation (i.e. no false positives) of something sort-of equivalent to the halting problem: if the program terminates, then block Y was executed. Cheers, Scott On Tue, Oct 2, 2012 at 7:43 PM, Jim Grosbach
2016 Mar 24
0
Open Project : Inter-procedural Register Allocation [GSoC 2016]
> On Mar 24, 2016, at 1:55 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> One more, just for fun: Inter-procedural stack allocation. That is of calls bar, bar needs 4 bytes of stack space. Instead of bar allocating 4 bytes, it adds an attribute to itself, then foo allocates 4 bytes of space at the bottom of the stack for bar to use. > > This is something that