similar to: [LLVMdev] Static Profiling - GSoC 2009

You said it was expensive, but if you had to put a big-o estimate on it, what would it be? -Thanks Jeff Kunkel On Tue, Nov 2, 2010 at 8:54 PM, Andrei Alvares <logytech at gmail.com> wrote: > Hello Jeff, > > On Tue, Nov 2, 2010 at 9:17 PM, Jeff Kunkel <jdkunk3 at gmail.com> wrote: > > My god! I would love a branch predictor! It would simplify many aspects > of >

My god! I would love a branch predictor! It would simplify many aspects of my register allocator. Second, I am surprised it did not make it into the tree. Since more is being done with register allocation as a while "RegAllocBasic" was just put in, I hope this is looked at again. Do you have a working svn copy? Also, could you send me a copy/link to that '94 paper off the list

Hi Jeff, There is an algorithm to build the dominator tree that is O(n2), where n is the number of nodes on the control flow graph. I believe exists another that is linear, but I don't which one of them is implemented in LLVM. The problem is that the branch predictor requires post dominance information. None of the LLVM basic passes require post dominance information (AFAIK), hence it is

Hello Jeff, On Tue, Nov 2, 2010 at 9:17 PM, Jeff Kunkel <jdkunk3 at gmail.com> wrote: > My god! I would love a branch predictor! It would simplify many aspects of > my register allocator. The branch predictor of the implementation is not as accurate as the one from the paper, but it is close enough. Unfortunately, the branch predictor is a very expensive pass, because it relies on

Chris, Chris Lattner wrote: > I would love to see any progress in this area. It is clearly an > important thing to tackle, and it is blocking other interesting > improvements in the code generator. It would also allow us to > eliminate a significant amount of weirdness that exists to hack around > this (e.g. switch lowering). we've been working on a whole-function

On Mar 25, 2008, at 9:40 AM, Dietmar Ebner wrote: > Chris, > > Chris Lattner wrote: >> I would love to see any progress in this area. It is clearly an >> important thing to tackle, and it is blocking other interesting >> improvements in the code generator. It would also allow us to >> eliminate a significant amount of weirdness that exists to hack >>

Evan Cheng wrote: > That's unfortunate. What kind of licensing issues are there? i've talked to our supporting company and they agreed to release the code to interested parties. it's not a copyleft license but the code can be used freely for private and research purposes. be warned that the code is merely a prototype implementation and not ready for inclusion in LLVM. it also

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

On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote: > The problem I've had is building an LLVM cross-compiler from Linux/ > x86 to Linux/ARM (as has another llvm-dev poster). Someone > mentioned to me off-list that he managed to get it to build, but I > haven't been able to reproduce the build using his instructions > (I'll post my results in another thread).

Thanks Andrei! I haven't read the paper. I would see whether this fulfills my requirements or whether I need to make any changes. --Kapil On Tue, Nov 2, 2010 at 12:43 PM, Andrei Alvares <logytech at gmail.com> wrote: > 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 >

Hi, this is the fourth in a series of patches to cleanup and improve the LLVM Profiling Infrastructure. It depends on the previous patches from http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-July/023569.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-July/023602.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-July/023642.html This patch introduces an implementation of the ProfileInfo

On Wed, Mar 11, 2009 at 3:21 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > Now that I have HLVM up and running on x86 and x64 I am interested in > testing > it out on an ARM in preparation for their imminent world domination. I > believe LLVM already has excellent support for the ARM thanks to Apple's > ARM-based products. However, I'd really like an ARM-based

On Mon, 22 Oct 2007, Dale Johannesen wrote: > In principle I think keeping IEEE float and double in an endian- > independent form in the IR files is a good idea. BUT: I'm told > retaining the ability to use files in the existing format is a > requirement (so floats still need to occupy 8 bytes). Since ARM target > doesn't currently work that one is a reasonable

On Thu, Mar 12, 2009 at 6:17 AM, Dietmar Ebner <ebner at complang.tuwien.ac.at>wrote: > On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote: > > The problem I've had is building an LLVM cross-compiler from Linux/ > > x86 to Linux/ARM (as has another llvm-dev poster). Someone > > mentioned to me off-list that he managed to get it to build, but I > > haven't

hi, we're trying to come up with a static compiler based on llvm for a 4- way vliw architecture with full support for predicated execution. a distinguishing feature is the omission of flag registers. instead, conditions can be paired with a particular instruction within the same bundle. a performance critical issue will be proper use of predicated execution. if-conversion can either

Now that I have HLVM up and running on x86 and x64 I am interested in testing it out on an ARM in preparation for their imminent world domination. I believe LLVM already has excellent support for the ARM thanks to Apple's ARM-based products. However, I'd really like an ARM-based consumer device suitable for developing and testing HLVM on, rather than using a cross compiler and

hi, Dale Johannesen wrote: > On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote: >> i'm trying to make some experiments with the ARM backend (llvm 2.1) >> and >> therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. >> >> however, the llvm-gcc frontend seems to cause troubles with single >> precision floating point values, i.e., they are

I know that this has been discussed (at least in passing) a few times on the list, but I couldn't locate a bug for it. Have any architectural plans been made for it? Are there architectural roadblocks with the current LLVM infrastructure that will complicate the process? What has demotivated the implementation of this so far (is it not that big a benefit on important targets, too

On Mar 24, 2008, at 10:47 PM, Christopher Lamb wrote: > I know that this has been discussed (at least in passing) a few > times on the list, but I couldn't locate a bug for it. Have any > architectural plans been made for it? Funny you bring this up. Evan and I were tossing around crazy ideas about this just today. If you're interested, maybe we should get together for

This proposal adds support for path profiling [Ball96] to LLVM. Path profiling compactly represents acyclic paths in a directed acyclic graph representation of the control flow graph of a routine. Instrumentation can be added to uniquely identify paths executed at runtime. Path profiles enable precise enumeration of the sequence of basic blocks executed in order for a particular path. Using path