Page MenuHomePhabricator

[DAGCombiner] allow transforming (select Cond, C +/- 1, C) to (add(ext Cond), C)
ClosedPublic

Authored by spatel on Mar 2 2017, 7:47 AM.

Details

Summary

select Cond, C +/- 1, C --> add(ext Cond), C -- with a target hook.

This is part of the ongoing process to obsolete D24480.

PowerPC is an obvious winner for this kind of transform because it has fast and complete bit-twiddling abilities but generally lousy conditional execution perf (although this might have changed in recent implementations).

x86 also sees some wins, but the effect is limited because these transforms already mostly exist in its target-specific combineSelectOfTwoConstants(). The fact that we see any x86 changes just shows that that code is a mess of special-case holes. We may be able to remove some of that logic if this goes in.

My guess is that other targets will want to enable this hook for most cases. The likely follow-ups would be to add value type and/or the constants themselves as parameters for the hook. As the tests in select_const.ll show, we can transform any select-of-constants to math/logic, but the general transform for any 2 constants needs one more instruction (multiply or 'and').

ARM is one target that I think may not want this for most cases. I see infinite loops there because it wants to use selects to enable conditionally executed instructions.

Diff Detail

Repository
rL LLVM

Event Timeline

spatel created this revision.Mar 2 2017, 7:47 AM
efriedma edited edge metadata.Mar 2 2017, 11:21 AM

All of the testcase changes you're showing here involve a select where the condition is a TRUNCATE (so the extension is free, so it's profitable to transform on all platforms). Does this have any impact on the more common patterns, like SELECT(SETCC)?

spatel added a comment.Mar 2 2017, 3:27 PM

All of the testcase changes you're showing here involve a select where the condition is a TRUNCATE (so the extension is free, so it's profitable to transform on all platforms). Does this have any impact on the more common patterns, like SELECT(SETCC)?

Excellent question...

For x86, if we have a setcc node, then everything I've tried so far that would be affected by this patch would also be caught in the target-specific combineSelectOfTwoConstants(), so there's no output difference.

For PPC, the code in this patch will fire too, but there is code that reverses the transform:

PPC DAG preprocessing replacing:
Old:    t20: i64 = add t19, Constant:i64<41>
New: t28: i64 = select t8, Constant:i64<42>, Constant:i64<41>

...so <tears forming>, we end up with isel -- or worse cmp/br. And so again, there is no output difference.

So the answer to your question for x86 and PPC (for different reasons) is: no, there is no impact on the common cases AFAICT.

Okay. Given that, why do we want to do this? Does it allow some useful refactoring of other code?

spatel added a comment.Mar 2 2017, 5:06 PM

Okay. Given that, why do we want to do this? Does it allow some useful refactoring of other code?

I haven't looked much at anything besides x86, but yes, at least for that target, we can eliminate custom code and plug the holes that are visible in this patch and probably others. My main motivation is that by putting this fold into the common DAGCombiner code any target will be able to pick it up easily. And that will help ease the restoration for the InstCombine that we currently only have half of:
https://reviews.llvm.org/rL75531
https://reviews.llvm.org/rL159230
...so the ultimate goal is to standardize the patterns in IR (we'll always canonicalize to select when possible) and then have a standard way to transform selects to math/logic here in codegen.

efriedma accepted this revision.Mar 3 2017, 11:42 AM

Okay, then it looks fine.

This revision is now accepted and ready to land.Mar 3 2017, 11:42 AM
This revision was automatically updated to reflect the committed changes.