[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