[PATCH] D46008: [X86][AArch64][NFC] Add tests for vector masked merge unfolding

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added inline comments.


================
Comment at: test/CodeGen/X86/unfold-masked-merge-vector-variablemask.ll:2
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=x86_64-unknown-linux-gnu -mattr=-sse,-sse2 < %s | FileCheck %s --check-prefix=CHECK-BASELINE
+; RUN: llc -mtriple=x86_64-unknown-linux-gnu -mattr=+sse,-sse2 < %s | FileCheck %s --check-prefix=CHECK-SSE
----------------
lebedev.ri wrote:
> RKSimon wrote:
> > lebedev.ri wrote:
> > > spatel wrote:
> > > > Why is this config interesting? IMO, it just distracts from the cases that we do care about, but I may not be seeing it.
> > > I think we do want to check that we don't do anything stupid in `andn`-less case,
> > > much like without `BMI` in scalar case. 
> > I agree, the non-SSE tests aren't very useful (and I'm a little dubious about SSE1 tbh).
> > 
> > What MIGHT be useful is a XOP pass:
> > 
> > ; RUN: llc -mtriple=x86_64-unknown-linux-gnu -mattr=+sse,-sse2 < %s | FileCheck %s --check-prefixes=CHECK,CHECK-SSE,CHECK-SSE1
> > ; RUN: llc -mtriple=x86_64-unknown-linux-gnu -mattr=+sse,+sse2 < %s | FileCheck %s --check-prefixes=CHECK,CHECK-SSE,CHECK-SSE2
> > ; RUN: llc -mtriple=x86_64-unknown-linux-gnu -mattr=+xop < %s | FileCheck %s --check-prefix=CHECK,CHECK-XOP
> > 
> > As XOP is the only X86 ISA with a bsl style vector instruction (PCMOV) - maybe add this to both x86 test files?
> If i drop baseline tests, which tests will verify what we do in that case?
> I know i needed them when working on D46528, i don't think anything else tests that.
> 
> Will look into `XOP`..
BTW, is this `--check-prefixes=` magic documented somewhere?
Especially, why is the `CHECK,CHECK-SSE,CHECK-SSE2` the correct order that works,
while `CHECK,CHECK-SSE,CHECK-SSE1,CHECK-SSE2` results in lost data?
I'm asking because i have tried the second variant, and failed.
Now that i have seen the first variant, i guess i understand the logic, but still..


Repository:
  rL LLVM

https://reviews.llvm.org/D46008