[llvm-dev] Oddity w/MachineBlockPlacement and Loops

[Philip Reames via llvm-dev]

I've posted a patch which addresses this:
http://reviews.llvm.org/D17830

On 02/23/2016 05:19 PM, Philip Reames 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 
> something.
>
> 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.
>
> Philip
>