[llvm-commits] [Review request] Jump threading and 'select'.

Frits van Bommel fvbommel at gmail.com
Wed Dec 15 02:03:38 PST 2010


On Wed, Dec 15, 2010 at 6:51 AM, Chris Lattner <clattner at apple.com> wrote:
> This looks ok to me.  Please merge this:
>
> +    if (TrueVal || FalseVal) {
> +      PredValueInfoTy Conds;
> +      if (ComputeValueKnownInPredecessors(SI->getCondition(), BB, Conds,
> +                                          WantInteger)) {
>
> Into something like this to reduce indentation:
>
> +    PredValueInfoTy Conds;
> +    if ((TrueVal || FalseVal) &&
>         ComputeValueKnownInPredecessors(SI->getCondition(), BB, Conds, ..
>
> and apply.

r121859.

> Is it helpful to know the condition of the select in one of the predecessors?

I haven't actually measured how often this fires on real code, but the
standard pass order does run -simplifycfg once before -jump-threading,
and -simplifycfg does have the tendency to turn some PHI nodes into
selects. So intuitively this might allow -jump-threading to recover
some of the "juicy" information that was previously lost by that.
On the other hand, since -scalarrepl doesn't run before that
-simplifycfg there probably won't be a lot of PHIs for it to eat yet,
so this case might only matter for PHIs inserted directly by the
frontend.

The second -jump-threading run might do better, once the code has been
optimized more.
But again, this is mostly guesswork.




More information about the llvm-commits mailing list