[llvm-commits] More aggressive speculation in SimplifyCFG

[Krzysztof Parzyszek]

On 1/22/2013 11:34 PM, Chandler Carruth wrote:
>
> I'm not really arguing for the specifics of this patch, but I do think
> there is a place for more aggressive speculation at the IR-level. But
> perhaps not for the common reasons people push for more speculation... ;]
>
> There are a number of IR-level optimizations which are significantly
> aided by forming a flatter CFG with simple value selection.  An obvious
> is the DAG building and combining being able to more effectively combine
> across basic block boundaries. There are similar issues with
> instcombine, instsimplify, etc, where we do a BB-local scan. When we
> detect very simple CFG patterns that can be replaced with flat code,
> minimal speculation and selects instead of phi nodes, I think it is
> often a Good Thing to do in order to simplify downstream optimizations.

I didn't realize that the early if-conversion was operating at the MI 
level.  We needed something that would work on the IR level, so that the 
subsequent IR optimizations would catch more opportunities.  Since it 
all happened a while ago I don't remember the specifics.  They came from 
EEMBC, so I most likely couldn't paste samples of code here anyways. 
But you're right---a late solution was not sufficient for us.


> Now, that said, I completely agree that the IR optimizers are hopeless
> at actually figuring out when to emit speculated code with cmov (or
> predication, or whatever the technique is). The early if-converter (or
> any passes built on top of the trace metrics and infrastructure you
> mentioned) are the right places to do that.
>
> What would make the most sense to me is for the IR optimizers to try to
> find the right mixture of speculation to simplify the CFG for other IR
> optimizations, and early if-conversion could both form a CFG for cases
> where speculation and cmov is the wrong fit, and flatten the CFG when it
> is the correct fit. Does the logic to expand a IR select formation into
> a CFG exist yet?

I think what would be useful is providing IR optimizations with some 
sort of feedback mechanism from the target backend.  This way they could 
at least use some guidance in making decisions like that.  The above is 
the reason why I submitted it disabled by default.  My thought was that 
if someone finds this useful, they could enable it for their purposes.

Converting selects into CFG would be useful to have (btw, we considered 
writing it, it just never happened).  I'm not sure if it would be more 
beneficial at the IR level than at the MI level though---this conversion 
would be motivated mostly by target-specific factors.  In such case, 
again we run into the problem of how to make good target-specific 
decisions at the IR level.

-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation