similar to: [LLVMdev] Question regarding basic-block placement optimization

On Oct 18, 2011, at 2:53 AM, Chandler Carruth wrote: > Hello, > > I'm working on basic-block placement optimizations based on branch probability information. I've run into a stumbling block though. One of the existing passes to do this, essentially a dead pass 'block-placement' operates on the IR, reordering the blocks of the function, and relying on the code generator

On Tue, Oct 18, 2011 at 2:59 PM, Cameron Zwarich <zwarich at apple.com> wrote: > On Oct 18, 2011, at 2:53 AM, Chandler Carruth wrote: > > > Hello, > > > > I'm working on basic-block placement optimizations based on branch > probability information. I've run into a stumbling block though. One of the > existing passes to do this, essentially a dead pass

On Tue, Oct 18, 2011 at 4:31 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Oct 18, 2011, at 3:07 PM, Chandler Carruth wrote: > > On Tue, Oct 18, 2011 at 2:59 PM, Cameron Zwarich <zwarich at apple.com>wrote: > >> I think this should really live as a CodeGen pass. Is there any good >> reason to make it an IR pass? >> > > So, as it

On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote: >> As for why it should be an IR pass, mostly because once the selection dag runs through the code, we can never recover all of the freedom we have at the IR level. To start with, splicing MBBs around requires known about the terminators (which we only some of the time do), and it requires re-writing them a touch to account for the

On Tue, Oct 18, 2011 at 6:58 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote: > > As for why it should be an IR pass, mostly because once the selection dag >> runs through the code, we can never recover all of the freedom we have at >> the IR level. To start with, splicing MBBs around requires known about

On Oct 18, 2011, at 3:07 PM, Chandler Carruth wrote: > On Tue, Oct 18, 2011 at 2:59 PM, Cameron Zwarich <zwarich at apple.com> wrote: > I think this should really live as a CodeGen pass. Is there any good reason to make it an IR pass? > > So, as it happens, I was *completely* wrong here. CodeGen correctly preserves the ordering of blocks from IR, *unless* it can do folding,

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

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.

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 Wed, Oct 19, 2011 at 3:24 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Oct 18, 2011 at 6:58 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > >> >> On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote: >> >> As for why it should be an IR pass, mostly because once the selection >>> dag runs through the code, we can never

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

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

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

Ok, I think I have a working pass that is based much more on what we've talked about here. The patch is attached. I'd love to commit it soon-ish and then start tweaking it based on feedback from you, others, and looking at how it actually works in the wild. It's essentially a re-write, so it may be hard to read... Let me know if some other form would be easier. Some responses to your

On Sun, Oct 23, 2011 at 1:11 AM, Chandler Carruth <chandlerc at google.com>wrote: > Ok, I think I have a working pass that is based much more on what we've > talked about here. The patch is attached. I'd love to commit it soon-ish and > then start tweaking it based on feedback from you, others, and looking at > how it actually works in the wild. After chatting briefly

On Oct 20, 2011, at 11:53 PM, Chandler Carruth wrote: > On Thu, Oct 20, 2011 at 10:53 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > 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. >

On Thu, Oct 20, 2011 at 10:53 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > 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

Hi John, It looks pretty good. Thanks for working on this. Some comments: 1. Some of the functions that you introduced, e.g. stringifyCSRegSet probably ought to be "static" and ifdef'ed out when NDEBUG is defined. 2. + // DEBUG + if (! MBB->empty() && ! CSRUsed[MBB].intersects(restore)) { + MachineInstr* MI = BeforeI; + DOUT <<

Hi Evan, Thanks very much for the review, I am implementing your suggestions today and will have the next patch together this weekend. A few questions/comments: On Thu, Mar 12, 2009 at 10:05 AM, Evan Cheng <echeng at apple.com> wrote: > > 1. Some of the functions that you introduced, e.g. stringifyCSRegSet > probably ought to be "static" and ifdef'ed out when NDEBUG

Hello folks, I think I've fixed everything left to be fixed in block placement, and I would really like for it to be on by default in 3.1: 1) I've been testing this as thoroughly as I can across a large amount of real-world code, so it shouldn't be too flaky. 2) The code has been checked in and reviewed previously. 3) It completes a significant missing feature in LLVM with