>>
>>>>> On 5 December 2011 13:10, Richard Guenther
>>>>> wrote:
>>>>>> On Mon, Dec 5, 2011 at 9:48 AM, Ira Rosen wrote:
>>>>>>>
>>>>>>>
>>>>>>> gcc-patches-ow...@gcc.gnu.org wrote on 05/12/2011
gt;>>> for this soon.
>>>>
>>>> On 5 December 2011 13:10, Richard Guenther
>>>> wrote:
>>>>> On Mon, Dec 5, 2011 at 9:48 AM, Ira Rosen wrote:
>>>>>>
>>>>>>
>>>>>> gcc-patches-o
gt;>>
>>>>> gcc-patches-ow...@gcc.gnu.org wrote on 05/12/2011 10:39:07 AM:
>>>>>
>>>>>> From: Michael Zolotukhin
>>>>>> To: Richard Guenther
>>>>>> Cc: gcc-patches@gcc.gnu.org, izamya...@gmail.com
>>
gt; wrote:
>>> On Mon, Dec 5, 2011 at 9:48 AM, Ira Rosen wrote:
>>>>
>>>>
>>>> gcc-patches-ow...@gcc.gnu.org wrote on 05/12/2011 10:39:07 AM:
>>>>
>>>>> From: Michael Zolotukhin
>>>>> To: Richard Guenther
t;>>> To: Richard Guenther
>>>> Cc: gcc-patches@gcc.gnu.org, izamya...@gmail.com
>>>> Date: 05/12/2011 10:39 AM
>>>> Subject: Re: [Patch] Increase array sizes in vect-tests to enable
>>>> 256-bit vectorization
>>>> Sent by: gcc-patc
t;> Subject: Re: [Patch] Increase array sizes in vect-tests to enable
>> 256-bit vectorization
>> Sent by: gcc-patches-ow...@gcc.gnu.org
>>
>> On 5 December 2011 10:14, Michael Zolotukhin
>> wrote:
>> > Ok, will several tests with short arrays be enough for th
gcc-patches-ow...@gcc.gnu.org wrote on 05/12/2011 10:39:07 AM:
> From: Michael Zolotukhin
> To: Richard Guenther
> Cc: gcc-patches@gcc.gnu.org, izamya...@gmail.com
> Date: 05/12/2011 10:39 AM
> Subject: Re: [Patch] Increase array sizes in vect-tests to enable
> 256-bit vecto
On 5 December 2011 10:14, Michael Zolotukhin
wrote:
> Ok, will several tests with short arrays be enough for that or should
> we keep all the original tests plus new ones with longer arrays?
BTW, there is another problem with current tests with short arrays -
scans are expecting specific number o
Ok, will several tests with short arrays be enough for that or should
we keep all the original tests plus new ones with longer arrays?
Michael
On 4 December 2011 15:44, Richard Guenther wrote:
> On Sat, Dec 3, 2011 at 5:54 PM, Michael Zolotukhin
> wrote:
>>> I mean, that, when 256-bit vectoriza
On Sat, Dec 3, 2011 at 5:54 PM, Michael Zolotukhin
wrote:
>> I mean, that, when 256-bit vectorization is enabled we still use 128bit
>> vectorization if the arrays are too short for 256bit vectorization. You'll
>> lose this test coverage when you change the array sizes.
> That's true, but do we n
> I mean, that, when 256-bit vectorization is enabled we still use 128bit
> vectorization if the arrays are too short for 256bit vectorization. You'll
> lose this test coverage when you change the array sizes.
That's true, but do we need all these test both with short and long
arrays? We could hav
On Fri, Dec 2, 2011 at 6:39 PM, Michael Zolotukhin
wrote:
>>
>> Shouldn't we add a variant for each testcase so that we still
>> excercise both 128-bit and 256-bit vectorization paths?
>
> These tests are still good to test 128-bit vectorization, the changes
> was made just to make sure that 256-b
Michael Zolotukhin wrote on 02/12/2011
08:11:41 PM:
>
> > Please don't change initial values to 0, we want to check that
everything
> > works fine for non-zeros as well.
> > There are several other occasions in the patch.
>
> Please check the update patch (attached).
This is ok with me.
Thanks
>
> Shouldn't we add a variant for each testcase so that we still
> excercise both 128-bit and 256-bit vectorization paths?
These tests are still good to test 128-bit vectorization, the changes
was made just to make sure that 256-bit vectorization is possible on
the tests.
Actually, It's just fir
gcc-patches-ow...@gcc.gnu.org wrote on 02/12/2011 06:23:25 PM:
> Hi,
>
> This patch increases array sizes in tests from vect.exp suite, thus
> enabling 256-bit vectorization where it's available.
>
> Ok for trunk?
--- a/gcc/testsuite/gcc.dg/vect/slp-24.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-24.c
2011/12/2 Michael Zolotukhin :
> Hi,
>
> This patch increases array sizes in tests from vect.exp suite, thus
> enabling 256-bit vectorization where it's available.
>
> Ok for trunk?
Shouldn't we add a variant for each testcase so that we still
excercise both 128-bit and 256-bit vectorization paths
16 matches
Mail list logo
