[PATCH] InstCombine: Transform select with and/or cond into select sequence
listmail at philipreames.com
Wed Feb 4 17:26:28 PST 2015
On 02/03/2015 08:59 PM, hfinkel at anl.gov wrote:
>> In my early tests the transformation was benficial on arm, aarch64, x86 but of course not on powerpc. Either the powerpc target should normalize into the other direction or we add another TargetTransformInfo flag that tells InstCombine which is the preferred form. I am not sure which to pick.
> This is fine for PPC too. LLVM's PPC backend stores boolean values in CR bit registers, and on modern cores with isel, this transformation seems fairly neutral. Your first example goes from:
> cmpw 0, 3, 6
> cmpw 1, 3, 7
> crandc 20, 4, 0
> isel 3, 4, 5, 20
> cmpw 0, 3, 7
> cmpw 7, 3, 6
> isel 4, 4, 5, 0
> isel 3, 5, 4, 28
> On a http://reviews.llvm.org/P7/http://reviews.llvm.org/P8, this seems pretty neutral (both the crandc and the isel are cracked). On the A2, you've increased the critical path length by 1 cycle (isel takes two cycles, but crandc only takes one). Nevertheless, I think that I can adjust for that during isel fairly easily.
> The real question, as far as InstCombine goes, is does this make the most-useful canonical form? I'd tend to think that the answer is no, because the logical operators seem more likely to be amenable to further simplification than chains of selects. I could certainly be wrong, however. Also, not all cores have conditional moves (although many now do). Another option is to put this in DAGCombine (or CodeGenPrep), and there you might as well make it target customizable (I'd likely disable it for the PPC A2).
I would weakly* prefer this not be in InstCombine. CGP seems like a
reasonable place for it.
* If anyone has a strong opinion or a good argument, feel free to ignore me.
> EMAIL PREFERENCES
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
More information about the llvm-commits