search for: blockplacement2

...shake it out. Maybe splicing a block into it current position will create a loop? Some random notes: - Please add a description of the algorithm. - Please add a comment to the BlockChain class. - Use a separate anonymous namespace per class, and don't indent for the namespace. +BlockChain *BlockPlacement2::CreateChain(MachineBasicBlock *BB) { + Chains.push_back(BlockChain(BlockToChain, BB)); + BlockToChain[BB] = &Chains.back(); + assert(ActiveChains.insert(&Chains.back())); + return &Chains.back(); +} Whoa, you are storing pointers into a growing vector. You should at least assert(C...

...abstraction seems overly generic and unnecessary. When you merge chains, why don't you delete the edge between the chains? Why do you run profile guided block layout after the existing CodePlacementOpt? Shouldn't it be the other way around so that CodePlacementOpt can cleanup loops, which BlockPlacement2 doesn't handle well? I think the answer is that BlockPlacement2 actually depends on loops being laid out sensibly before running, but that needs to be explained. > > Be careful about placing too much trust in the behavior of branch probabilities. They go out of whack when they saturate....

...e now, and we just use the BB -> successor list -> block-to-chain mapping sequence to deduce edges when needed. Why do you run profile guided block layout after the existing > CodePlacementOpt? Shouldn't it be the other way around so that > CodePlacementOpt can cleanup loops, which BlockPlacement2 doesn't handle > well? Yep, I just slapped it in there for testing. I've put it immediately before the CodePlacementOpt pass, but I know very little about the other passes. Let me know if there is a better home for it. > I think the answer is that BlockPlacement2 actually depends...

...39;s almost certainly not ready for that just yet. I would like to see this go in ASAP under a flag. I prefer to see development as commits rather than a series of updated patches. Could you rename it to MachineBlockPlacement.cpp first, though? That makes it clear it's a CodeGen pass, and the BlockPlacement2 name is icky. > I'm more hopeful that we can delete the existing block placement pass, and direct anyone interested in profile file guided stuff to write a simple pass to load profiles into metadata. I suspect this pass is already superior to that one. I also see it as a replacement for Co...

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

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

...D At least some of it (the loop alignment from CodePlacementOpt) is obvious how to port across, but I'm sure there will be more tricky elements around the loop structures. Could you rename it to MachineBlockPlacement.cpp first, though? That makes > it clear it's a CodeGen pass, and the BlockPlacement2 name is icky. > Yea, the 2 thing was only intended to work around a brief duplication with the existing pass. MachineBlockPlacement solves both problems nicely. > > I'm more hopeful that we can delete the existing block placement pass, > and direct anyone interested in profile fi...