[llvm-commits] More aggressive speculation in SimplifyCFG

[Evan Cheng]

On Jan 23, 2013, at 6:55 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:

> 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.

I can believe that. In that case, I would argue that you want a specific LLVM IR pass which flatten CFG's. I don't think simplifycfg is the right place to do this.

Evan

> 
> 
>> 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