similar to: [LLVMdev] Call profiling and function placement in object file

Hi, I would like to learn the details regarding what exactly PGO does for basic block layout/code placement optimizations in llvm. Could you please point me to some descriptions? Is it close to this paper (Karl Pettis and Robert C. Hansen. 1990. Profile guided code positioning. PLDI'90) http://perso.ensta-paristech.fr/~bmonsuez/Cours/B6-4/Articles/papers15.pdf? Whether it is purely

Hi; I was planning to implement a profile guided optimization technique in LLVM. In the open source projects list of the LLVM site; I saw "code layout" is a transformation that can be worth looking at as it will use of profiles (possibly path profiles). So I was thinking of implementing either Pettis-Hansen's (Profile guided code positioning, Pettis & Hansen) or Gloy's

Hi, Gratian, I did that Summer of Code. I used a different algorithm than Patterson's. It is a constraint system by Su and Wagner, which is more modern, and has some advantages over older works. In particular, it is non-iterative. I found it very hard to compare it with Patterson's analysis, because there is not much description in that paper. However, there is another paper, by

Hi! I'm a student who would like to participate on Google SOC for LLVM, and was thinking about what project to pick. I saw on the "Open projects" page that Value Range Propagation is not implemented and thought about doing it, based on a paper by Patterson (it's also used by GCC). But then I saw that last year someone did a Range Analysis pass that seems to do pretty much the

Hi! My name is Gratian and I would like to participate to GSOC 2011. I'm interested in profile-guided optimizations, and I want to implement two optimizations that can bring tangible benefits for most applications: profile-guided function inlining and basic block positioning. Inlining can be greatly improved if we take into consideration how many times the function we want to inline was

1. Summary I will implement two optimizations in the LLVM compiler, both based on runtime profile information: an inlining mechanism that takes the call frequency into consideration, and a better basic block placement algorithm. 2. The project LLVM now includes an efficient framework [1] for instrumenting an application and collecting edge and path profile information. Profile-guided

On Dec 28, 2010, at 9:39 AM, Lup Gratian wrote: > I recently downloaded LLVM 2.8 and started playing with the optimizations a bit. > I saw something curious while trying the following function: > > int g(unsigned int a) { > unsigned int c[100]; > c[10] = a; > c[11] = a; > unsigned int b = c[10] + c[11]; > > if(b > a*2) a = 4; > else a = 8; >

On Dec 28, 2010, at 12:48 PM, Chris Lattner wrote: > On Dec 28, 2010, at 9:39 AM, Lup Gratian wrote: >> I find it strange that it hasn't found that %add and %mul have the same value, %cmp would be then false, selecting and returning 15. If 'a' is replaced by a constant it works. > > You're right, that is a missed optimization. I added it to the missed optimization

Dear LLVM Developers: I am an undergraduate summer research student supervised by José Nelson Amaral at the University of Alberta. My work will primarily involve value profiling and path profiling. Andreas Neustifter is planning some changes to the profiling related code in LLVM (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/020396.html). Are any of these changes in yet? Which

On Oct 20, 2011, at 9:56 AM, Chandler Carruth wrote: > A new patch is attached that is *much* less of a rough draft. Sorry for any confusion due to the early state of the patch. Thanks, Chandler. This is great stuff. > Still, I never intended this to be on-by-default at first. This is a starting point, that I hope can be improved into something that is on-by-default eventually, but

Thanks for all of the comments Andy and Jakob. A new patch is attached that is *much* less of a rough draft. Sorry for any confusion due to the early state of the patch. Also, many many thanks to Jakob for his explanation of how the branches between MBBs should be handled, and Andy, Jim, and Eric who helped answer my questions on IRC when I ran into stumbling blocks. Also, Nick, who shoulder

On Oct 19, 2011, at 7:56 AM, Jakob Stoklund Olesen wrote: >> This is still *very* much a rough draft, but it's probably better to review that the previous patch. One big caveat, I know I have an iteration bug in here somewhere that is inf-looping. Just ran out of steam debugging it, will pick it back up again later today to shake it out. > > Some random notes: > > - Please

I recently downloaded LLVM 2.8 and started playing with the optimizations a bit. I saw something curious while trying the following function: int g(unsigned int a) { unsigned int c[100]; c[10] = a; c[11] = a; unsigned int b = c[10] + c[11]; if(b > a*2) a = 4; else a = 8; return a + 7; } The generated code, with -O3 activated, is define i32 @g(i32 a) nounwind readnone { %add = shl i32

Hi, I'm trying to install R from an rpm locally to my account (the reason I'm not doing it through yast/yast2/zypper is that the sys admin isn't yet willing to install it, and doesn't want to support it, but will help me support it if I install it locally -- in short, policy problems rather than technical). Below is the SuSE version, Kernel version, and rpm install error I'm

On Mon, Jan 16, 2017 at 2:31 PM, Davide Italiano <davide at freebsd.org> wrote: > On Mon, Jan 16, 2017 at 2:07 PM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > > > > On Jan 16, 2017, at 1:47 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > > > > > On Mon, Jan 16, 2017 at 1:25 PM, Davide Italiano <davide at freebsd.org>

Hi, I have written a code layout feedback directed optimization pass, which currently works for basic block reordering and function reordering. It very effectively improves the speedup (we could improve Python by 30%). The profiling method is window based context sensitive which is based on reference affinity (

On Mon, Jan 16, 2017 at 12:31 PM, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Do we have any open projects on LLD? > > I know we usually try to avoid any big "projects" and mainly add/fix things > in response to user needs, but just wondering if somebody has any ideas. > I'm not particularly active in lld anymore, but the last big item I'd

On Mon, Jan 16, 2017 at 3:34 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Mon, Jan 16, 2017 at 3:32 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> >> >> On Mon, Jan 16, 2017 at 2:31 PM, Davide Italiano <davide at freebsd.org> >> wrote: >> >>> On Mon, Jan 16, 2017 at 2:07 PM, Mehdi Amini <mehdi.amini at

From: Dave Airlie <airlied at redhat.com> When a buffer is evicted for memory pressure or TTM evict all, the placement is set to the eviction domain, this means the buffer never gets revalidated on the next exec to the correct domain. I think this should be fine to use the initial domain from the object creation, as least with VM_BIND this won't change after init so this should be the

On Oct 19, 2011, at 5:50 AM, Chandler Carruth wrote: > Ok, wow that wasn't hard at all. Awesome ;-) > This is still *very* much a rough draft, but it's probably better to review that the previous patch. One big caveat, I know I have an iteration bug in here somewhere that is inf-looping. Just ran out of steam debugging it, will pick it back up again later today to shake it out.