[LLVMdev] Simplifying selects + arm stuff

[Evan Cheng]

On Nov 10, 2010, at 11:39 PM, Chris Lattner wrote:
>> 
> 
> Yeah, that's not nearly as good as "%r = and i32 %x, %y" :)
> 
> Note that:
> 
> %z = select i1 %cond, i32 -1, i32 %x
> %s = and i32 %z, %y
> 
> Is a "conditional and".  It would be interesting to know if the ARM backend gets this as a single predicated 'and' instruction (similarly for the 'or' and 'xor' version of these patterns).  I bet not, which is bad if instcombine is canonicalizing this way.

On ARM, an instruction predicated on false predicate is still executed so it's frequently undesirable. Because llvm canonicalize to select instruction, it already generates significantly more predicated instructions than gcc. We have seen some regressions due to overly aggressive select formation.

By definition select requires both source operands to be evaluated. Given how good branch predicators are these days, I'm not surprised it often turns branching code performs better. ICC also almost never generates conditional moves.

Evan


> 
>> Do you have any thoughts for how to get the best of both worlds?  How about
>> only applying your transform when one of the operands (eg B) is a constant?
> 
> I don't think that's a great solution, because reducing # uses of a value is general goodness (increases odds that "hasOneUse()" xforms will kick in for example).  
> 
>> Alternatively, it could look at uses of the select and try to simplify those
>> first using InstructionSimplify (not sure if instcombine is allowed to
>> simplify a different instruction to the one it is visiting), or check to see
>> if some or all uses of the select would be simplified by InstructionSimplify,
>> and not perform the transform if so.
> 
> Instead of turning this into a phase ordering issue, I'd rather increase the power of the folding logic to catch the general form.  In this case, instead of handling this in instsimplify, why not handle this in reassociate?
> 
> This is conceptually no different than (x & y & x) -> (x & y), it's just that in this case you have: (x & y & (x or -1)) which should fold to (x & y) just the same.
> 
> -Chris
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101112/aa8632e9/attachment.html>