[llvm] r179957 - SimplifyCFG: If convert single conditional stores

Andrew Trick atrick at apple.com
Thu May 2 16:42:23 PDT 2013


On Apr 29, 2013, at 2:59 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:

> On 4/24/2013 1:47 PM, Chandler Carruth wrote:
>> 
>> I feel like we need a better strategy long-term. Increasingly, I'm of
>> the opinion that as we move away from the SelectionDAG's basic block
>> limitations, we should also move away from canonicalizing to the
>> if-converted code. These days I would rather see us add utilities to
>> LLVM to look across basic blocks which form PHI-only CFGs as-if they
>> were straight line code, and to have the canonical form of predicated
>> values be PHI-only CFGs. This has a nice advantage of simplifying the IR
>> model, and being strictly more general than selects. However, it
>> *requires* that we don't have a basic-block granularity hard limitation
>> in passes, and that's just not the world we live in currently. Maybe
>> eventually.
> 
> This may or may not work in practice.  For example, loop unrolling may be beneficial in cases where the code is straight-line, but not when it has branches in it.  With canonicalization either way we won't always know if the final code will be a straight-line or not until long after optimizations that may be interested in such knowledge have taken place.

It's perfectly fine and consistent with LLVM philosophy for a loop unroller that runs late in the pipeline, after canonicalization, to query target information and if-convert as necessary to expose unrolling. That's exactly what the loop vectorizer does. The tension is between doing things like if-conversion and unrolling in an IR pass where the cost model is very rough, vs. an MI pass where register pressure and resource counts are very precise. LLVM let's you do it in both places depending on how much you want to invest in target-specific optimization.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130502/f6a947ac/attachment.html>


More information about the llvm-commits mailing list