[llvm-commits] More aggressive speculation in SimplifyCFG

[Andrew Trick]

On Jan 25, 2013, at 7:52 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:

> On 1/25/2013 2:32 AM, Andrew Trick wrote:
>> 
>> Early passes, like SimplifyCFG, whose job is to canonicalize IR should
>> try to avoid using heuristics driven by thresholds. No disagreement I'm
>> sure.
> 
> This is an argument to have a version of the SimplifyCFG pass that would avoid target-specific transformations, and a version that would do whatever the target architecture prefers.

>> But along the same lines, when we do need heuristics to avoid IR
>> bloat, they should be derived purely from the IR, not TTI.
> 
> The patch I submitted does not cause code bloat.  The concern there was the speculation, which may or may not be beneficial on a particular target.

I understand. I jumped on this thread to discuss the broader issue because it's related to Chandler's TTI changes.

I don't have a fundamental problem with two versions of SimplifyCFG. One for canonicalization and one for lowering. In fact, I'd like to do that with other passes...

But in this case I think it would be cleaner to have a separate FlattenCFG pass that is only enabled by "special" targets, with common helpers factored in Utils. I really think that aggressive if-conversion is not a simplification. Piling ISEL optimizations like this into SimplifyCFG sets a bad precedent. This is related to my broader point that I don't want SimplifyCFG to depend on TTI.

I think moving the optimization is a mechanical change. If you disagree I could be convinced the other way.

-Andy