[llvm-commits] [llvm] r163302 - in /llvm/trunk: lib/Transforms/Utils/SimplifyCFG.cpp test/Transforms/SimplifyCFG/switch_create.ll test/Transforms/SimplifyCFG/switch_to_lookup_table.ll

[Chandler Carruth]

On Mon, Sep 10, 2012 at 1:35 AM, Nadav Rotem <nrotem at apple.com> wrote:

>
> On Sep 9, 2012, at 1:45 AM, Chandler Carruth <chandlerc at google.com> wrote:
>
> My idea had been to extend the IR to directly represent the concept of
> this operation. Currently, we have a 'br' instruction to represent binary
> control flow selection, and we have a 'switch' instruction to represent
> N-way control flow selection. We also have 'select' to represent binary
> value selection, but no instruction to represent N-way value selection. I
> suggested adding a new instruction 'selectswitch' (or some better name) to
> support selecting over N values based on an integer much the way switch
> works.
>
>
> How would you use selectswitch ?  Will it allows you to do things that you
> can't do today ?
>

It will allow some of the speculative value-forwarding optimizations that
currently fire on selects to also fire on the code paths where the current
SimplifyCFG fires. For example, the forward-propagating constant folding
done in the inliner can forward values through selects when the i1 variable
is a constant. Before this pass, it would pick the correct sucessor basic
block, but couldn't trace that through to the PHI-node and prove that only
the one predecessor was live, thus collapsing the PHI node to a single
incoming value. With this pass, everything is indirected through memory.

There are probably other places where this applies, but I expect most of
them to take this form.

The second form, which i suspect is a touch less common, is allowing passes
to know that a selectswitch could take on one of some small N number of
values. If the operands are all constants, or are all the same etc, passes
can simplify the reasoning about the selectswitch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120910/8a371a48/attachment.html>