Re: r254262 - [X86][SSE2] Added SSE2 IR + assembly codegen builtin tests

2015-12-24 Thread Sanjay Patel via cfe-commits 
In case anyone is planning to fix this sort of thing universally, I broke:
test/CodeGen/aarch64-poly64.c
with:
http://reviews.llvm.org/rL256394

and hopefully worked-around the fail with:
http://reviews.llvm.org/rL256395

That test file doesn't even pretend to be independent of LLVM
optimizations; it's checking asm after using -O3.


On Sun, Nov 29, 2015 at 5:38 PM, Eric Christopher via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Yeah, I've been trying to fix them. I didn't see them go in. :(
>
> And yes, that's a good way to tie them. It shouldn't be bad though.
> Separation of concerns and all.
>
> -eric
>
> On Sun, Nov 29, 2015, 3:10 PM Robinson, Paul <
> paul_robin...@playstation.sony.com> wrote:
>
> It looks like there are a number of the *-builtins.c tests that have grown
> this feature of testing both IR and asm.  Seems to have sprung from PR24580.
>
>
>
>
>
>
> Simon, if you're concerned about bitrot, I'd think you could have comments
> in the Clang test citing the LLVM test, and vice versa.  It's not a
> guarantee but it certainly should help.
>
> --paulr
>
>
>
> *From:* cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] *On
> Behalf Of *Eric Christopher via cfe-commits
> *Sent:* Sunday, November 29, 2015 2:21 PM
> *To:* Simon Pilgrim; cfe-commits@lists.llvm.org
> *Subject:* Re: r254262 - [X86][SSE2] Added SSE2 IR + assembly codegen
> builtin tests
>
>
>
> There's no reason a split set of tests would fail at doing this. You can
> test that the IR is what you expect and then that the backend tests it as
> well. It's very simple to do.
>
>
>
> On Sun, Nov 29, 2015, 2:08 PM Simon Pilgrim 
> wrote:
>
> So the problem we’re trying to solve is it make sure that in debug builds,
> clang compiles c/c++ intrinsics in the headers down to assembly that is
> very close to the expected instruction.
>
>
>
> What we had before (testing c/c++ to IR results in clang/test/CodeGen and
> testing with llc on ‘similar' IR in llvm/test/CodeGen/X86) was very
> sensitive to bitrot, especially as we’ve put so much effort into removing
> what target specific intrinsics that we can.
>
>
>
> I’m happy to split the tests but would prefer that they are both being
> tested from c/c++ source (that at least is unlikely to ever change) so that
> we have a better chance of keeping track of any big changes - so is there
> anywhere in the clang project that they can be put?
>
>
>
> On 29 Nov 2015, at 21:47, Eric Christopher  wrote:
>
>
>
> In the backend. If at all possible IR tests only in the front end. Same
> with optimization etc.
>
>
>
> On Sun, Nov 29, 2015, 1:46 PM Simon Pilgrim 
> wrote:
>
> I can try - if asm is not supposed to go in tests/CodeGen where is it
> supposed to go?
>
>
>
> On 29 Nov 2015, at 20:38, Eric Christopher 
> gmail.com > wrote:
>
>
>
> This is amazing... And entirely the wrong place for the asm tests. :)
>
> Would you mind splitting this test case in two with an IR test for clang
> and an asm test for llvm?
>
> Thanks!
>
>
>
> On Sun, Nov 29, 2015, 12:25 PM Simon Pilgrim via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: rksimon
> Date: Sun Nov 29 14:23:00 2015
> New Revision: 254262
>
> URL: http:// <http://llvm.org/viewvc/llvm-project?rev=254262&view=rev>
> llvm.org <http://llvm.org/viewvc/llvm-project?rev=254262&view=rev>/
> <http://llvm.org/viewvc/llvm-project?rev=254262&view=rev>viewvc
> <http://llvm.org/viewvc/llvm-project?rev=254262&view=rev>/
> <http://llvm.org/viewvc/llvm-project?rev=254262&view=rev>llvm-project
> <http://llvm.org/viewvc/llvm-project?rev=254262&view=rev>
> ?rev=254262&view=rev
> <http://llvm.org/viewvc/llvm-project?rev=254262&view=rev>
> Log:
> [X86][SSE2] Added SSE2 IR + assembly codegen builtin tests
>
> Improved tests as discussed in PR24580
>
> Added:
> cfe/trunk/test/CodeGen/sse2-builtins.c
>
> Added: cfe/trunk/test/CodeGen/sse2-builtins.c
> URL: http://
> <http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
> llvm.org
> <http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
> /
> <http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
> viewvc
> <http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
> /
> <http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&v

Re: r254262 - [X86][SSE2] Added SSE2 IR + assembly codegen builtin tests

2015-11-29 Thread Eric Christopher via cfe-commits 
Yeah, I've been trying to fix them. I didn't see them go in. :(

And yes, that's a good way to tie them. It shouldn't be bad though.
Separation of concerns and all.

-eric

On Sun, Nov 29, 2015, 3:10 PM Robinson, Paul <
paul_robin...@playstation.sony.com> wrote:

It looks like there are a number of the *-builtins.c tests that have grown
this feature of testing both IR and asm.  Seems to have sprung from PR24580.






Simon, if you're concerned about bitrot, I'd think you could have comments
in the Clang test citing the LLVM test, and vice versa.  It's not a
guarantee but it certainly should help.

--paulr



*From:* cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] *On Behalf
Of *Eric Christopher via cfe-commits
*Sent:* Sunday, November 29, 2015 2:21 PM
*To:* Simon Pilgrim; cfe-commits@lists.llvm.org
*Subject:* Re: r254262 - [X86][SSE2] Added SSE2 IR + assembly codegen
builtin tests



There's no reason a split set of tests would fail at doing this. You can
test that the IR is what you expect and then that the backend tests it as
well. It's very simple to do.



On Sun, Nov 29, 2015, 2:08 PM Simon Pilgrim  wrote:

So the problem we’re trying to solve is it make sure that in debug builds,
clang compiles c/c++ intrinsics in the headers down to assembly that is
very close to the expected instruction.



What we had before (testing c/c++ to IR results in clang/test/CodeGen and
testing with llc on ‘similar' IR in llvm/test/CodeGen/X86) was very
sensitive to bitrot, especially as we’ve put so much effort into removing
what target specific intrinsics that we can.



I’m happy to split the tests but would prefer that they are both being
tested from c/c++ source (that at least is unlikely to ever change) so that
we have a better chance of keeping track of any big changes - so is there
anywhere in the clang project that they can be put?



On 29 Nov 2015, at 21:47, Eric Christopher  wrote:



In the backend. If at all possible IR tests only in the front end. Same
with optimization etc.



On Sun, Nov 29, 2015, 1:46 PM Simon Pilgrim  wrote:

I can try - if asm is not supposed to go in tests/CodeGen where is it
supposed to go?



On 29 Nov 2015, at 20:38, Eric Christopher 
gmail.com > wrote:



This is amazing... And entirely the wrong place for the asm tests. :)

Would you mind splitting this test case in two with an IR test for clang
and an asm test for llvm?

Thanks!



On Sun, Nov 29, 2015, 12:25 PM Simon Pilgrim via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

Author: rksimon
Date: Sun Nov 29 14:23:00 2015
New Revision: 254262

URL: http:// <http://llvm.org/viewvc/llvm-project?rev=254262&view=rev>
llvm.org <http://llvm.org/viewvc/llvm-project?rev=254262&view=rev>/
<http://llvm.org/viewvc/llvm-project?rev=254262&view=rev>viewvc
<http://llvm.org/viewvc/llvm-project?rev=254262&view=rev>/
<http://llvm.org/viewvc/llvm-project?rev=254262&view=rev>llvm-project
<http://llvm.org/viewvc/llvm-project?rev=254262&view=rev>
?rev=254262&view=rev
<http://llvm.org/viewvc/llvm-project?rev=254262&view=rev>
Log:
[X86][SSE2] Added SSE2 IR + assembly codegen builtin tests

Improved tests as discussed in PR24580

Added:
cfe/trunk/test/CodeGen/sse2-builtins.c

Added: cfe/trunk/test/CodeGen/sse2-builtins.c
URL: http://
<http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
llvm.org
<http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
/
<http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
viewvc
<http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
/
<http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
llvm-project
<http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
/
<http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
cfe
<http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
/trunk/test/
<http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
CodeGen
<http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
/
<http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
sse2-builtins.c
<http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
?rev=254262&view=auto
<http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto>
==
--- cfe/t

RE: r254262 - [X86][SSE2] Added SSE2 IR + assembly codegen builtin tests

2015-11-29 Thread Robinson, Paul via cfe-commits 
Resending because I forgot to explicitly CC the list AGAIN. :-P

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> Simon Pilgrim via cfe-commits
> Sent: Sunday, November 29, 2015 12:23 PM
> To: cfe-commits@lists.llvm.org
> Subject: r254262 - [X86][SSE2] Added SSE2 IR + assembly codegen builtin
> tests
> 
> Author: rksimon
> Date: Sun Nov 29 14:23:00 2015
> New Revision: 254262
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=254262&view=rev
> Log:
> [X86][SSE2] Added SSE2 IR + assembly codegen builtin tests
> 
> Improved tests as discussed in PR24580
> 
> Added:
> cfe/trunk/test/CodeGen/sse2-builtins.c
> 
> Added: cfe/trunk/test/CodeGen/sse2-builtins.c
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-
> builtins.c?rev=254262&view=auto
> ==
> 
> --- cfe/trunk/test/CodeGen/sse2-builtins.c (added)
> +++ cfe/trunk/test/CodeGen/sse2-builtins.c Sun Nov 29 14:23:00 2015
> @@ -0,0 +1,1656 @@
> +// REQUIRES: x86-registered-target
> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2 -
> emit-llvm -o - -Werror | FileCheck %s --check-prefix=DAG
> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2 -
> fno-signed-char -emit-llvm -o - -Werror | FileCheck %s --check-prefix=DAG
> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2 -
> S -o - -Werror | FileCheck %s --check-prefix=ASM
> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2 -
> fno-signed-char -S -o - -Werror | FileCheck %s --check-prefix=ASM
> +
> +// Don't include mm_malloc.h, it's system specific.
> +#define __MM_MALLOC_H
> +
> +#include 
> +
> +__m128i test_mm_add_epi8(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_add_epi8
> +  // DAG: add <16 x i8>

Because DAG is a special suffix for FileCheck, I'd prefer not to have
it as the prefix.  I mean, it should work; but in a FileCheck context, 
DAG actually means something and I'd like not to have any more excuses 
than usual to be confused about reading FileChecks.
Thanks,
--paulr

> +  //
> +  // ASM-LABEL: test_mm_add_epi8
> +  // ASM: paddb
> +  return _mm_add_epi8(A, B);
> +}
> +
> +__m128i test_mm_add_epi16(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_add_epi16
> +  // DAG: add <8 x i16>
> +  //
> +  // ASM-LABEL: test_mm_add_epi16
> +  // ASM: paddw
> +  return _mm_add_epi16(A, B);
> +}
> +
> +__m128i test_mm_add_epi32(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_add_epi32
> +  // DAG: add <4 x i32>
> +  //
> +  // ASM-LABEL: test_mm_add_epi32
> +  // ASM: paddd
> +  return _mm_add_epi32(A, B);
> +}
> +
> +__m128i test_mm_add_epi64(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_add_epi64
> +  // DAG: add <2 x i64>
> +  //
> +  // ASM-LABEL: test_mm_add_epi64
> +  // ASM: paddq
> +  return _mm_add_epi64(A, B);
> +}
> +
> +__m128d test_mm_add_pd(__m128d A, __m128d B) {
> +  // DAG-LABEL: test_mm_add_pd
> +  // DAG: fadd <2 x double>
> +  //
> +  // ASM-LABEL: test_mm_add_pd
> +  // ASM: addpd
> +  return _mm_add_pd(A, B);
> +}
> +
> +__m128d test_mm_add_sd(__m128d A, __m128d B) {
> +  // DAG-LABEL: test_mm_add_sd
> +  // DAG: fadd double
> +  //
> +  // ASM-LABEL: test_mm_add_sd
> +  // ASM: addsd
> +  return _mm_add_sd(A, B);
> +}
> +
> +__m128i test_mm_adds_epi8(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_adds_epi8
> +  // DAG: call <16 x i8> @llvm.x86.sse2.padds.b
> +  //
> +  // ASM-LABEL: test_mm_adds_epi8
> +  // ASM: paddsb
> +  return _mm_adds_epi8(A, B);
> +}
> +
> +__m128i test_mm_adds_epi16(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_adds_epi16
> +  // DAG: call <8 x i16> @llvm.x86.sse2.padds.w
> +  //
> +  // ASM-LABEL: test_mm_adds_epi16
> +  // ASM: paddsw
> +  return _mm_adds_epi16(A, B);
> +}
> +
> +__m128i test_mm_adds_epu8(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_adds_epu8
> +  // DAG: call <16 x i8> @llvm.x86.sse2.paddus.b
> +  //
> +  // ASM-LABEL: test_mm_adds_epu8
> +  // ASM: paddusb
> +  return _mm_adds_epu8(A, B);
> +}
> +
> +__m128i test_mm_adds_epu16(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_adds_epu16
> +  // DAG: call <8 x i16> @llvm.x86.sse2.paddus.w
> +  //
> +  // ASM-LABEL: test_mm_adds_epu16
> +  // ASM: paddusw
> +  return _mm_adds_epu16(A, B);
> +}
> +
> +__m128d test_mm_and_pd(__m128d A, __m128d B) {
> +  // DAG-LABEL: test_mm_and_pd
> +  // DAG: and <4 x i32>
> +  //
> +  // ASM-LABEL: test_mm_and_pd
> +  // ASM: pand
> +  return _mm_and_pd(A, B);
> +}
> +
> +__m128i test_mm_and_si128(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_and_si128
> +  // DAG: and <2 x i64>
> +  //
> +  // ASM-LABEL: test_mm_and_si128
> +  // ASM: andps
> +  return _mm_and_si128(A, B);
> +}
> +
> +__m128i test_mm_avg_epu8(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_avg_epu8
> +  // DAG: call <16 x i8> @llvm.x86.sse2.pavg.b
> +  //
> +  // ASM-LABEL: test_mm_avg_epu8
> +  // ASM: pavgb
>

Re: r254262 - [X86][SSE2] Added SSE2 IR + assembly codegen builtin tests

2015-11-29 Thread Simon Pilgrim via cfe-commits 
OK I’ll see what I can do to split the tests with a -O0/-fast-isel llc version. 
I understand the work is straightforward, as I said my fear is that by breaking 
the connection we end up with syncing issues with the backend testing for IR 
patterns that the frontend no longer generates, which is what we hit in the 
first place. Please don’t revert this just yet - I’ll start getting this moved 
over in the next few days. Cheers, Simon.

> On 29 Nov 2015, at 22:20, Eric Christopher  wrote:
> 
> There's no reason a split set of tests would fail at doing this. You can test 
> that the IR is what you expect and then that the backend tests it as well. 
> It's very simple to do.
> 
> 
> On Sun, Nov 29, 2015, 2:08 PM Simon Pilgrim  > wrote:
> So the problem we’re trying to solve is it make sure that in debug builds, 
> clang compiles c/c++ intrinsics in the headers down to assembly that is very 
> close to the expected instruction.
> 
> What we had before (testing c/c++ to IR results in clang/test/CodeGen and 
> testing with llc on ‘similar' IR in llvm/test/CodeGen/X86) was very sensitive 
> to bitrot, especially as we’ve put so much effort into removing what target 
> specific intrinsics that we can.
> 
> I’m happy to split the tests but would prefer that they are both being tested 
> from c/c++ source (that at least is unlikely to ever change) so that we have 
> a better chance of keeping track of any big changes - so is there anywhere in 
> the clang project that they can be put?
> 
>> On 29 Nov 2015, at 21:47, Eric Christopher > > wrote:
>> 
>> In the backend. If at all possible IR tests only in the front end. Same with 
>> optimization etc.
>> 
>> 
>> On Sun, Nov 29, 2015, 1:46 PM Simon Pilgrim > > wrote:
>> I can try - if asm is not supposed to go in tests/CodeGen where is it 
>> supposed to go? 
>> 
>>> On 29 Nov 2015, at 20:38, Eric Christopher >> > wrote:
>>> 
>>> This is amazing... And entirely the wrong place for the asm tests. :)
>>> 
>>> Would you mind splitting this test case in two with an IR test for clang 
>>> and an asm test for llvm?
>>> 
>>> Thanks!
>>> 
>>> 
>>> On Sun, Nov 29, 2015, 12:25 PM Simon Pilgrim via cfe-commits 
>>> mailto:cfe-commits@lists.llvm.org>> wrote:
>>> Author: rksimon
>>> Date: Sun Nov 29 14:23:00 2015
>>> New Revision: 254262
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=254262&view=rev 
>>> 
>>> Log:
>>> [X86][SSE2] Added SSE2 IR + assembly codegen builtin tests
>>> 
>>> Improved tests as discussed in PR24580
>>> 
>>> Added:
>>> cfe/trunk/test/CodeGen/sse2-builtins.c
>>> 
>>> Added: cfe/trunk/test/CodeGen/sse2-builtins.c
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto
>>>  
>>> 
>>> ==
>>> --- cfe/trunk/test/CodeGen/sse2-builtins.c (added)
>>> +++ cfe/trunk/test/CodeGen/sse2-builtins.c Sun Nov 29 14:23:00 2015
>>> @@ -0,0 +1,1656 @@
>>> +// REQUIRES: x86-registered-target
>>> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2 
>>> -emit-llvm -o - -Werror | FileCheck %s --check-prefix=DAG
>>> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2 
>>> -fno-signed-char -emit-llvm -o - -Werror | FileCheck %s --check-prefix=DAG
>>> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2 -S 
>>> -o - -Werror | FileCheck %s --check-prefix=ASM
>>> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2 
>>> -fno-signed-char -S -o - -Werror | FileCheck %s --check-prefix=ASM
>>> +
>>> +// Don't include mm_malloc.h, it's system specific.
>>> +#define __MM_MALLOC_H
>>> +
>>> +#include 
>>> +
>>> +__m128i test_mm_add_epi8(__m128i A, __m128i B) {
>>> +  // DAG-LABEL: test_mm_add_epi8
>>> +  // DAG: add <16 x i8>
>>> +  //
>>> +  // ASM-LABEL: test_mm_add_epi8
>>> +  // ASM: paddb
>>> +  return _mm_add_epi8(A, B);
>>> +}
>>> +
>>> +__m128i test_mm_add_epi16(__m128i A, __m128i B) {
>>> +  // DAG-LABEL: test_mm_add_epi16
>>> +  // DAG: add <8 x i16>
>>> +  //
>>> +  // ASM-LABEL: test_mm_add_epi16
>>> +  // ASM: paddw
>>> +  return _mm_add_epi16(A, B);
>>> +}
>>> +
>>> +__m128i test_mm_add_epi32(__m128i A, __m128i B) {
>>> +  // DAG-LABEL: test_mm_add_epi32
>>> +  // DAG: add <4 x i32>
>>> +  //
>>> +  // ASM-LABEL: test_mm_add_epi32
>>> +  // ASM: paddd
>>> +  return _mm_add_epi32(A, B);
>>> +}
>>> +
>>> +__m128i test_mm_add_epi64(__m128i A, __m128i B) {
>>> +  // DAG-LABEL: test_mm_add_epi64
>>> +  // DAG: add <2 x i64>
>>> +  //
>>> +  // ASM-LABEL: test_mm_add_epi64
>>> +  // ASM: paddq
>>> +  return _mm_add_epi64(A, B);
>>> +}
>>> +
>>> +__m128d test_mm_add_pd(__m128d A, __m128d B) {
>>> +  // DAG

Re: r254262 - [X86][SSE2] Added SSE2 IR + assembly codegen builtin tests

2015-11-29 Thread Eric Christopher via cfe-commits 
There's no reason a split set of tests would fail at doing this. You can
test that the IR is what you expect and then that the backend tests it as
well. It's very simple to do.

On Sun, Nov 29, 2015, 2:08 PM Simon Pilgrim  wrote:

> So the problem we’re trying to solve is it make sure that in debug builds,
> clang compiles c/c++ intrinsics in the headers down to assembly that is
> very close to the expected instruction.
>
> What we had before (testing c/c++ to IR results in clang/test/CodeGen and
> testing with llc on ‘similar' IR in llvm/test/CodeGen/X86) was very
> sensitive to bitrot, especially as we’ve put so much effort into removing
> what target specific intrinsics that we can.
>
> I’m happy to split the tests but would prefer that they are both being
> tested from c/c++ source (that at least is unlikely to ever change) so that
> we have a better chance of keeping track of any big changes - so is there
> anywhere in the clang project that they can be put?
>
> On 29 Nov 2015, at 21:47, Eric Christopher  wrote:
>
> In the backend. If at all possible IR tests only in the front end. Same
> with optimization etc.
>
> On Sun, Nov 29, 2015, 1:46 PM Simon Pilgrim 
> wrote:
>
>> I can try - if asm is not supposed to go in tests/CodeGen where is it
>> supposed to go?
>>
>> On 29 Nov 2015, at 20:38, Eric Christopher  wrote:
>>
>> This is amazing... And entirely the wrong place for the asm tests. :)
>>
>> Would you mind splitting this test case in two with an IR test for clang
>> and an asm test for llvm?
>>
>> Thanks!
>>
>> On Sun, Nov 29, 2015, 12:25 PM Simon Pilgrim via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rksimon
>>> Date: Sun Nov 29 14:23:00 2015
>>> New Revision: 254262
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=254262&view=rev
>>> Log:
>>> [X86][SSE2] Added SSE2 IR + assembly codegen builtin tests
>>>
>>> Improved tests as discussed in PR24580
>>>
>>> Added:
>>> cfe/trunk/test/CodeGen/sse2-builtins.c
>>>
>>> Added: cfe/trunk/test/CodeGen/sse2-builtins.c
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto
>>>
>>> ==
>>> --- cfe/trunk/test/CodeGen/sse2-builtins.c (added)
>>> +++ cfe/trunk/test/CodeGen/sse2-builtins.c Sun Nov 29 14:23:00 2015
>>> @@ -0,0 +1,1656 @@
>>> +// REQUIRES: x86-registered-target
>>> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2
>>> -emit-llvm -o - -Werror | FileCheck %s --check-prefix=DAG
>>> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2
>>> -fno-signed-char -emit-llvm -o - -Werror | FileCheck %s --check-prefix=DAG
>>> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2
>>> -S -o - -Werror | FileCheck %s --check-prefix=ASM
>>> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2
>>> -fno-signed-char -S -o - -Werror | FileCheck %s --check-prefix=ASM
>>> +
>>> +// Don't include mm_malloc.h, it's system specific.
>>> +#define __MM_MALLOC_H
>>> +
>>> +#include 
>>> +
>>> +__m128i test_mm_add_epi8(__m128i A, __m128i B) {
>>> +  // DAG-LABEL: test_mm_add_epi8
>>> +  // DAG: add <16 x i8>
>>> +  //
>>> +  // ASM-LABEL: test_mm_add_epi8
>>> +  // ASM: paddb
>>> +  return _mm_add_epi8(A, B);
>>> +}
>>> +
>>> +__m128i test_mm_add_epi16(__m128i A, __m128i B) {
>>> +  // DAG-LABEL: test_mm_add_epi16
>>> +  // DAG: add <8 x i16>
>>> +  //
>>> +  // ASM-LABEL: test_mm_add_epi16
>>> +  // ASM: paddw
>>> +  return _mm_add_epi16(A, B);
>>> +}
>>> +
>>> +__m128i test_mm_add_epi32(__m128i A, __m128i B) {
>>> +  // DAG-LABEL: test_mm_add_epi32
>>> +  // DAG: add <4 x i32>
>>> +  //
>>> +  // ASM-LABEL: test_mm_add_epi32
>>> +  // ASM: paddd
>>> +  return _mm_add_epi32(A, B);
>>> +}
>>> +
>>> +__m128i test_mm_add_epi64(__m128i A, __m128i B) {
>>> +  // DAG-LABEL: test_mm_add_epi64
>>> +  // DAG: add <2 x i64>
>>> +  //
>>> +  // ASM-LABEL: test_mm_add_epi64
>>> +  // ASM: paddq
>>> +  return _mm_add_epi64(A, B);
>>> +}
>>> +
>>> +__m128d test_mm_add_pd(__m128d A, __m128d B) {
>>> +  // DAG-LABEL: test_mm_add_pd
>>> +  // DAG: fadd <2 x double>
>>> +  //
>>> +  // ASM-LABEL: test_mm_add_pd
>>> +  // ASM: addpd
>>> +  return _mm_add_pd(A, B);
>>> +}
>>> +
>>> +__m128d test_mm_add_sd(__m128d A, __m128d B) {
>>> +  // DAG-LABEL: test_mm_add_sd
>>> +  // DAG: fadd double
>>> +  //
>>> +  // ASM-LABEL: test_mm_add_sd
>>> +  // ASM: addsd
>>> +  return _mm_add_sd(A, B);
>>> +}
>>> +
>>> +__m128i test_mm_adds_epi8(__m128i A, __m128i B) {
>>> +  // DAG-LABEL: test_mm_adds_epi8
>>> +  // DAG: call <16 x i8> @llvm.x86.sse2.padds.b
>>> +  //
>>> +  // ASM-LABEL: test_mm_adds_epi8
>>> +  // ASM: paddsb
>>> +  return _mm_adds_epi8(A, B);
>>> +}
>>> +
>>> +__m128i test_mm_adds_epi16(__m128i A, __m128i B) {
>>> +  // DAG-LABEL: test_mm_adds_epi16
>>> +  // DAG: call <8 x i16> @llvm.x86.sse2.padds.w
>>> +  //
>>> +  // ASM-LABEL: test_mm_adds_epi16
>>

Re: r254262 - [X86][SSE2] Added SSE2 IR + assembly codegen builtin tests

2015-11-29 Thread Simon Pilgrim via cfe-commits 
So the problem we’re trying to solve is it make sure that in debug builds, 
clang compiles c/c++ intrinsics in the headers down to assembly that is very 
close to the expected instruction.

What we had before (testing c/c++ to IR results in clang/test/CodeGen and 
testing with llc on ‘similar' IR in llvm/test/CodeGen/X86) was very sensitive 
to bitrot, especially as we’ve put so much effort into removing what target 
specific intrinsics that we can.

I’m happy to split the tests but would prefer that they are both being tested 
from c/c++ source (that at least is unlikely to ever change) so that we have a 
better chance of keeping track of any big changes - so is there anywhere in the 
clang project that they can be put?

> On 29 Nov 2015, at 21:47, Eric Christopher  wrote:
> 
> In the backend. If at all possible IR tests only in the front end. Same with 
> optimization etc.
> 
> 
> On Sun, Nov 29, 2015, 1:46 PM Simon Pilgrim  > wrote:
> I can try - if asm is not supposed to go in tests/CodeGen where is it 
> supposed to go? 
> 
>> On 29 Nov 2015, at 20:38, Eric Christopher > > wrote:
>> 
>> This is amazing... And entirely the wrong place for the asm tests. :)
>> 
>> Would you mind splitting this test case in two with an IR test for clang and 
>> an asm test for llvm?
>> 
>> Thanks!
>> 
>> 
>> On Sun, Nov 29, 2015, 12:25 PM Simon Pilgrim via cfe-commits 
>> mailto:cfe-commits@lists.llvm.org>> wrote:
>> Author: rksimon
>> Date: Sun Nov 29 14:23:00 2015
>> New Revision: 254262
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=254262&view=rev 
>> 
>> Log:
>> [X86][SSE2] Added SSE2 IR + assembly codegen builtin tests
>> 
>> Improved tests as discussed in PR24580
>> 
>> Added:
>> cfe/trunk/test/CodeGen/sse2-builtins.c
>> 
>> Added: cfe/trunk/test/CodeGen/sse2-builtins.c
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto
>>  
>> 
>> ==
>> --- cfe/trunk/test/CodeGen/sse2-builtins.c (added)
>> +++ cfe/trunk/test/CodeGen/sse2-builtins.c Sun Nov 29 14:23:00 2015
>> @@ -0,0 +1,1656 @@
>> +// REQUIRES: x86-registered-target
>> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2 
>> -emit-llvm -o - -Werror | FileCheck %s --check-prefix=DAG
>> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2 
>> -fno-signed-char -emit-llvm -o - -Werror | FileCheck %s --check-prefix=DAG
>> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2 -S 
>> -o - -Werror | FileCheck %s --check-prefix=ASM
>> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2 
>> -fno-signed-char -S -o - -Werror | FileCheck %s --check-prefix=ASM
>> +
>> +// Don't include mm_malloc.h, it's system specific.
>> +#define __MM_MALLOC_H
>> +
>> +#include 
>> +
>> +__m128i test_mm_add_epi8(__m128i A, __m128i B) {
>> +  // DAG-LABEL: test_mm_add_epi8
>> +  // DAG: add <16 x i8>
>> +  //
>> +  // ASM-LABEL: test_mm_add_epi8
>> +  // ASM: paddb
>> +  return _mm_add_epi8(A, B);
>> +}
>> +
>> +__m128i test_mm_add_epi16(__m128i A, __m128i B) {
>> +  // DAG-LABEL: test_mm_add_epi16
>> +  // DAG: add <8 x i16>
>> +  //
>> +  // ASM-LABEL: test_mm_add_epi16
>> +  // ASM: paddw
>> +  return _mm_add_epi16(A, B);
>> +}
>> +
>> +__m128i test_mm_add_epi32(__m128i A, __m128i B) {
>> +  // DAG-LABEL: test_mm_add_epi32
>> +  // DAG: add <4 x i32>
>> +  //
>> +  // ASM-LABEL: test_mm_add_epi32
>> +  // ASM: paddd
>> +  return _mm_add_epi32(A, B);
>> +}
>> +
>> +__m128i test_mm_add_epi64(__m128i A, __m128i B) {
>> +  // DAG-LABEL: test_mm_add_epi64
>> +  // DAG: add <2 x i64>
>> +  //
>> +  // ASM-LABEL: test_mm_add_epi64
>> +  // ASM: paddq
>> +  return _mm_add_epi64(A, B);
>> +}
>> +
>> +__m128d test_mm_add_pd(__m128d A, __m128d B) {
>> +  // DAG-LABEL: test_mm_add_pd
>> +  // DAG: fadd <2 x double>
>> +  //
>> +  // ASM-LABEL: test_mm_add_pd
>> +  // ASM: addpd
>> +  return _mm_add_pd(A, B);
>> +}
>> +
>> +__m128d test_mm_add_sd(__m128d A, __m128d B) {
>> +  // DAG-LABEL: test_mm_add_sd
>> +  // DAG: fadd double
>> +  //
>> +  // ASM-LABEL: test_mm_add_sd
>> +  // ASM: addsd
>> +  return _mm_add_sd(A, B);
>> +}
>> +
>> +__m128i test_mm_adds_epi8(__m128i A, __m128i B) {
>> +  // DAG-LABEL: test_mm_adds_epi8
>> +  // DAG: call <16 x i8> @llvm.x86.sse2.padds.b
>> +  //
>> +  // ASM-LABEL: test_mm_adds_epi8
>> +  // ASM: paddsb
>> +  return _mm_adds_epi8(A, B);
>> +}
>> +
>> +__m128i test_mm_adds_epi16(__m128i A, __m128i B) {
>> +  // DAG-LABEL: test_mm_adds_epi16
>> +  // DAG: call <8 x i16> @llvm.x86.sse2.padds.w
>> +  //
>> +  // ASM-LABEL: test_mm_adds_epi16
>> +  // ASM: paddsw
>> +  return _mm_adds_epi16(A, B);
>> +}
>> +
>> +__m128i test_mm_adds_epu8(__m12

Re: r254262 - [X86][SSE2] Added SSE2 IR + assembly codegen builtin tests

2015-11-29 Thread Eric Christopher via cfe-commits 
This is amazing... And entirely the wrong place for the asm tests. :)

Would you mind splitting this test case in two with an IR test for clang
and an asm test for llvm?

Thanks!

On Sun, Nov 29, 2015, 12:25 PM Simon Pilgrim via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rksimon
> Date: Sun Nov 29 14:23:00 2015
> New Revision: 254262
>
> URL: http://llvm.org/viewvc/llvm-project?rev=254262&view=rev
> Log:
> [X86][SSE2] Added SSE2 IR + assembly codegen builtin tests
>
> Improved tests as discussed in PR24580
>
> Added:
> cfe/trunk/test/CodeGen/sse2-builtins.c
>
> Added: cfe/trunk/test/CodeGen/sse2-builtins.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse2-builtins.c?rev=254262&view=auto
>
> ==
> --- cfe/trunk/test/CodeGen/sse2-builtins.c (added)
> +++ cfe/trunk/test/CodeGen/sse2-builtins.c Sun Nov 29 14:23:00 2015
> @@ -0,0 +1,1656 @@
> +// REQUIRES: x86-registered-target
> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2
> -emit-llvm -o - -Werror | FileCheck %s --check-prefix=DAG
> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2
> -fno-signed-char -emit-llvm -o - -Werror | FileCheck %s --check-prefix=DAG
> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2
> -S -o - -Werror | FileCheck %s --check-prefix=ASM
> +// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin -target-feature +sse2
> -fno-signed-char -S -o - -Werror | FileCheck %s --check-prefix=ASM
> +
> +// Don't include mm_malloc.h, it's system specific.
> +#define __MM_MALLOC_H
> +
> +#include 
> +
> +__m128i test_mm_add_epi8(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_add_epi8
> +  // DAG: add <16 x i8>
> +  //
> +  // ASM-LABEL: test_mm_add_epi8
> +  // ASM: paddb
> +  return _mm_add_epi8(A, B);
> +}
> +
> +__m128i test_mm_add_epi16(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_add_epi16
> +  // DAG: add <8 x i16>
> +  //
> +  // ASM-LABEL: test_mm_add_epi16
> +  // ASM: paddw
> +  return _mm_add_epi16(A, B);
> +}
> +
> +__m128i test_mm_add_epi32(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_add_epi32
> +  // DAG: add <4 x i32>
> +  //
> +  // ASM-LABEL: test_mm_add_epi32
> +  // ASM: paddd
> +  return _mm_add_epi32(A, B);
> +}
> +
> +__m128i test_mm_add_epi64(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_add_epi64
> +  // DAG: add <2 x i64>
> +  //
> +  // ASM-LABEL: test_mm_add_epi64
> +  // ASM: paddq
> +  return _mm_add_epi64(A, B);
> +}
> +
> +__m128d test_mm_add_pd(__m128d A, __m128d B) {
> +  // DAG-LABEL: test_mm_add_pd
> +  // DAG: fadd <2 x double>
> +  //
> +  // ASM-LABEL: test_mm_add_pd
> +  // ASM: addpd
> +  return _mm_add_pd(A, B);
> +}
> +
> +__m128d test_mm_add_sd(__m128d A, __m128d B) {
> +  // DAG-LABEL: test_mm_add_sd
> +  // DAG: fadd double
> +  //
> +  // ASM-LABEL: test_mm_add_sd
> +  // ASM: addsd
> +  return _mm_add_sd(A, B);
> +}
> +
> +__m128i test_mm_adds_epi8(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_adds_epi8
> +  // DAG: call <16 x i8> @llvm.x86.sse2.padds.b
> +  //
> +  // ASM-LABEL: test_mm_adds_epi8
> +  // ASM: paddsb
> +  return _mm_adds_epi8(A, B);
> +}
> +
> +__m128i test_mm_adds_epi16(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_adds_epi16
> +  // DAG: call <8 x i16> @llvm.x86.sse2.padds.w
> +  //
> +  // ASM-LABEL: test_mm_adds_epi16
> +  // ASM: paddsw
> +  return _mm_adds_epi16(A, B);
> +}
> +
> +__m128i test_mm_adds_epu8(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_adds_epu8
> +  // DAG: call <16 x i8> @llvm.x86.sse2.paddus.b
> +  //
> +  // ASM-LABEL: test_mm_adds_epu8
> +  // ASM: paddusb
> +  return _mm_adds_epu8(A, B);
> +}
> +
> +__m128i test_mm_adds_epu16(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_adds_epu16
> +  // DAG: call <8 x i16> @llvm.x86.sse2.paddus.w
> +  //
> +  // ASM-LABEL: test_mm_adds_epu16
> +  // ASM: paddusw
> +  return _mm_adds_epu16(A, B);
> +}
> +
> +__m128d test_mm_and_pd(__m128d A, __m128d B) {
> +  // DAG-LABEL: test_mm_and_pd
> +  // DAG: and <4 x i32>
> +  //
> +  // ASM-LABEL: test_mm_and_pd
> +  // ASM: pand
> +  return _mm_and_pd(A, B);
> +}
> +
> +__m128i test_mm_and_si128(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_and_si128
> +  // DAG: and <2 x i64>
> +  //
> +  // ASM-LABEL: test_mm_and_si128
> +  // ASM: andps
> +  return _mm_and_si128(A, B);
> +}
> +
> +__m128i test_mm_avg_epu8(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_avg_epu8
> +  // DAG: call <16 x i8> @llvm.x86.sse2.pavg.b
> +  //
> +  // ASM-LABEL: test_mm_avg_epu8
> +  // ASM: pavgb
> +  return _mm_avg_epu8(A, B);
> +}
> +
> +__m128i test_mm_avg_epu16(__m128i A, __m128i B) {
> +  // DAG-LABEL: test_mm_avg_epu16
> +  // DAG: call <8 x i16> @llvm.x86.sse2.pavg.w
> +  //
> +  // ASM-LABEL: test_mm_avg_epu16
> +  // ASM: pavgw
> +  return _mm_avg_epu16(A, B);
> +}
> +
> +__m128i test_mm_bslli_si128(__m128i A) {
> +  // DAG-LABEL: test_mm_bslli_si128
> +  // DAG