Differential D45563
[X86][AArch64][NFC] Add tests for masked merge unfolding Authored by lebedev.ri on Apr 12 2018, 5:01 AM.
Details This is PR37104. PR6773 will introduce an IR canonicalization that is likely bad for the end assembly.
Diff Detail
Event TimelineComment Actions Added some more tests with constant mask, for a good measure. Comment Actions Split x86 testcase into scalar and vector files, halving amount of RUN-lines in each of them. Comment Actions Don't know what changes are planned here, but this is on the right track. We want to have coverage of the possible canonical IR variations for various targets. PowerPC with Altivec has a vsel instruction if you want even more coverage, but I don't think the PPC backend has the isel pattern-matching logic to produce that currently (cc @nemanjai).
Comment Actions I'm working on that right now, got it working, maybe will update this + post the dagcombiner part (that is where i should have put it, right?) in a few hours.
Downside: i dropped vector tests for now, only only handle scalars for now. Comment Actions Yes, this will be in DAGCombiner.
That's actually preferred. Small steps - easier to review and fix when the bug reports come in. :) Comment Actions Not sure this answer is pertinent any longer, but on PPC we can generate the VSX version of the vector select (xxsel) for rather specific situations. See test/CodeGen/PowerPC/vselect-constants.ll and test/CodeGen/PowerPC/vsx.ll. Comment Actions I think it's still valid. Didn't mean to be cryptic - here's the vector example from this patch compiled for PPC64le: define <4 x i32> @out_vec(<4 x i32> %x, <4 x i32> %y, <4 x i32> %mask) {
%mx = and <4 x i32> %x, %mask
%notmask = xor <4 x i32> %mask, <i32 -1, i32 -1, i32 -1, i32 -1>
%my = and <4 x i32> %y, %notmask
%r = or <4 x i32> %mx, %my
ret <4 x i32> %r
}$ ./llc -o - vsel.ll -mtriple=powerpc64le xxsel 0, 35, 34, 36 ?
Comment Actions Revisited tests once, more, added some more complex patterns (with non-trivial 'y' and/or 'm'), that i expect could be failed to be matched.
Comment Actions LGTM. You could increase diversity in the constant mask tests by not using a single-string-of-set-bits constant (eg 0x0f0f0f0f instead of 0x0000ffff). Comment Actions But since we don't do anything (not fold, not unfold) with these patterns Comment Actions I wouldn't add more tests, but different constants might show the variety of codegen options that AArch is using on these sequences (x86 probably has no differences in that respect?). Comment Actions Split tests with variable mask and constant mask into separate files, add a bit more tests with different constant mask patterns. | ||||||||||||||||||||||||
Not sure this RUN adds much value - I think SSE is required by the x86-64 ABI, so we may already be in undefined territory with these tests. :)
A target with -mattr=avx may be slightly more interesting, but there might not be enough ISA difference there to even make that worthwhile.