[PATCH][X86] SSE2 cvtsd2ss instruction expects two operands

[Quentin Colombet]

On Oct 23, 2013, at 8:06 AM, Cameron McInally <cameron.mcinally at nyu.edu> wrote:

> On Tue, Oct 22, 2013 at 11:11 PM, Craig Topper <craig.topper at gmail.com> wrote:
>> For this case you can probably copy the avx-intrinsics.ll test case for this
>> intrinsic and create an sse2-intrinsics.ll. There appear to be several more
>> intrinsics that aren't being tested on sse2 so if you want to add tests for
>> them that would be awesome.
+1

> 
> Ah, interesting. Thanks, Craig.
> 
> This looks like it needs a good bit of work. I notice that the SSE
> intrinsic test cases are not as well organized as the AVX, FMA, and
> XOP intrinsics. It would be nice to bring SSE up to par.
> 
> Ideally, here is what I would like to do:
> 
> 1) Replicate the intrinsic tests covered in avx-intinsics-x86.ll for
> their SSE equivalents. To do this, I suggest adding several new .ll
> files. One for each subclass of the SSE intrinsics.
> 
> sse-intrinsics-x86.ll
> sse2-intrinsics-x86.ll
> sse3-intrinsics-x86.ll
> ssse3-intrinsics-x86.ll
> sse41-intrinsics-x86.ll
> sse42-intrinsics-x86.ll
> 
> This would organize the SSE intrinsic tests a bit better, but is not
> without issue. I suspect that there would be some immediate
> double-coverage in the test base.
Double-couvrage is better than no coverage at all :).

> Cleaning this up would need some
> future care.
> 
> 2) Add more robust CHECKs to these intrinsic tests, including those in
> avx-intrinsics-x86.ll and friends. Currently, these CHECKs look for
> the instruction name, but ignore the operand classes and count.
> 
> Quentin mentioned using a CHECK-NOT for the issue at hand:
> 
> define @fct(<some args>) {
> ; CHECK-NOT: <expected instruction> <regex op1>, <regex op2>, <regex op3>
> <simple use of your instrinsic>
> }
> 
> This is a good solution for our current problem. But, it is not so
> clear that it would scale well.
Agreed, generally speaking, you should check for what you want (CHECK).
If you are going into systematic tests of SSE intrinsics, this is definitely what I would do.

> Ideally, it would be nice to check for
> the case we really want, instead of one-of-many cases that we do not
> want. Of course, this depends on the expressiveness of the CHECK
> mechanism, which is something I have no intuition built around.
CHECK mechanism is pretty expressive, you can have a look here for the details:
http://llvm.org/docs/CommandGuide/FileCheck.html

-Quentin
> So, I
> do not have a good solution right now. It is something that I would
> have to think about.
> 
> In the meantime, please advise if you would like to go ahead with the
> SSE test clean-up.
> 
> -Cameron