[llvm-dev] Oddity w/MachineBlockPlacement and Loops
John Criswell via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 24 07:47:02 PST 2016
On a related note, Rahman Lavaee has been working on optimizing code
layout with LLVM. His approach uses a trace of the program, so it may
not be applicable to what you're doing, but I thought I should let you
know since it works on a similar problem.
I believe his code is at https://github.com/rlavaee/code-layout-optimizer.
Rahman, does this code do the function-level code layout, the basic
block layout optimization, or both?
On 2/23/16 8:19 PM, Philip Reames via llvm-dev wrote:
> I'm getting some odd behavior out of MBP and was hoping someone
> knowledge of the code might be able to give some guidance. Fair
> warning, I'm trying to describe a problem in code I don't really
> understand, so if something doesn't make sense, assume I misunderstood
> The problematic case I'm seeing is that cold blocks are being placed
> between the preheader and header of a hot loop. This has the result
> of adding a bunch of cold code spread through out the code rather than
> grouped all together at the end of the function.
> From what I can tell tracing through the code, the critical decision
> that goes wrong is when we're visiting the preheader after forming a
> (correct) chain for the loop itself. When selecting a successor to
> merge with, we appear to not be considering the loop even though the
> loop hasn't been rotated and the header would be ideal for fallthrough.
> In particular, we're printing the "(prob) (non-cold CFG conflict)"
> debug output message for the successor of the preheader which is the
> header. If I'm reading this code correctly, it's identifying the fact
> there's a global more important predecessor for the header (i.e. the
> latch block), but it doesn't seem to be account for the fact that the
> latch block has already been combined into the header's chain. Unless
> I'm misreading something, we *should* be able to merge the loop chain
> with the preheader chain in it's entirety right?
> At least one on example I've looked at, adding an early exit from
> BadCFGConflict loop when Pred and Succ are part of the same chain does
> appear to give the expected result, but I don't understand the code
> well enough to reason about whether that is generally a correct thing
> to do or not.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
Department of Computer Science, University of Rochester
More information about the llvm-dev