search for: codeplacementopt

...t2 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 CodePlacementOpt.cpp, so I think your flag should run your pass instead of CodePlacementOpt rather than before or after it. You should simply clone the loop alignment stuff, it's pretty trivial. /jakob

...ete the edge between the chains? > No good reason. The edges were a wart on the entire design. They're gone 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....

..., especially in the presence of critical edges? Why not layout blocks according to MachineLoopInfo? The SCC 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 ab...

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.

...feature additions we've talked about here. I'm fine either way, so its really what makes things easier on your end. I'll definitely want review on all of it as some of this (especially the loop structure issues) is still a bit new to me. =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 in...

...e shown on the left, the abstract parallel IR interface is is in the middle, and the representation specific implementations is on the right. Optimization (A)nalysis/(T)ransformation Impl. --------------------------------------------------------------------------- CodePlacementOpt \ /---> ParallelRegionInfo (A) ---------|-> KMPCImpl (A) RegionExpander -\ | | GOMPImpl (A) AttributeAnnotator -|-|---> ParallelCommunicationInfo (A) --/ ... BarrierElimination -/ | VariablePrivatization / \---> ParallelIR/Builder (...

...l go ahead and commit to it over the next few days. > Done, and in progress. SHould have the loop alignment stuff cloned right away, and then i'll start looking at the loop structure issues. I'll probably have some questions for you and/or andy about exactly how that should work, whether CodePlacementOpt is doing the right thing, etc. Your work looks good and there's talk of making this the default layout pass. So let's figure out the goals and requirements. We agree that preserving "structure" of the CFG is important in the absence of profile information to the contrary. This is...

...this is moving from llvm-commits to llvm-dev. On Feb 10, 2012, at 12:14 PM, Sergei Larin <slarin at codeaurora.org> wrote: > 1) Can a BB presented to the MI scheduler be _not_ terminated (end on a non > terminator MI) under any circumstances? Below you are speaking about "Empty > blocks, or blocks with only a single instruction that not a terminator..." - > What