On Thu, Aug 22, 2013 at 8:50 AM, Xinliang David Li wrote:
>> The effect on runtime is not correlated to
>> either (which means the vectorizer cost model is rather bad), but integer
>> code usually does not benefit at all.
>
> The cost model does need some tuning. For instance, GCC vectorizer
> doe
On Fri, Aug 23, 2013 at 5:16 AM, Richard Biener
wrote:
> Xinliang David Li wrote:
>>Interesting idea!
>
> In the past have already arranged for re-use of the epilogue loop and the
> scalar loop, so the situation was even worse.
>
> Note that re-use prevents complete peeling of the epilogue which
On Fri, Aug 23, 2013 at 02:16:35PM +0200, Richard Biener wrote:
> Xinliang David Li wrote:
> >Interesting idea!
>
> In the past have already arranged for re-use of the epilogue loop and the
> scalar loop, so the situation was even worse.
>
> Note that re-use prevents complete peeling of the epi
Xinliang David Li wrote:
>Interesting idea!
In the past have already arranged for re-use of the epilogue loop and the
scalar loop, so the situation was even worse.
Note that re-use prevents complete peeling of the epilogue which is often
profitable. Combining the prologue will introduce a mis
Interesting idea!
David
On Thu, Aug 22, 2013 at 4:46 PM, Cong Hou wrote:
> Another opportunity to reduce the code size is combining the scalar version
> from loop versioning, the prolog and the epilog of loop peeling. I manually
> made the following function for foo(). The running time does not
On Thu, Aug 22, 2013 at 1:24 AM, Ondřej Bílka wrote:
> On Wed, Aug 21, 2013 at 11:50:34PM -0700, Xinliang David Li wrote:
>> > The effect on runtime is not correlated to
>> > either (which means the vectorizer cost model is rather bad), but integer
>> > code usually does not benefit at all.
>>
>>
On Wed, Aug 21, 2013 at 11:50:34PM -0700, Xinliang David Li wrote:
> > The effect on runtime is not correlated to
> > either (which means the vectorizer cost model is rather bad), but integer
> > code usually does not benefit at all.
>
> The cost model does need some tuning. For instance, GCC vect
> The effect on runtime is not correlated to
> either (which means the vectorizer cost model is rather bad), but integer
> code usually does not benefit at all.
The cost model does need some tuning. For instance, GCC vectorizer
does peeling aggressively, but peeling in many cases can be avoided
w
One problem I have with the vectorizer on by default is that it
enables tree loop unrolling, which sometimes generates quite
bloated/weird code and it's unclear if it helps.
Would it be possible to only do the unrolling when vectorizing?
Also I suspect the trade off on vectorizing is different
b
s also a common practice in other compilers:
>>>>>>
>>>>>> 1) Intel's ICC turns on vectorizer at O2 by default and it has been
>>>>>> the case for many years;
>>>>>>
>>>>>> 2) Most recently, LLVM tu
d the newly announced AVX-512 further doubles the
>>>>> size. The benefit we can get from vectorization will be larger and
>>>>> larger. This is also a common practice in other compilers:
>>>>>
>>>>> 1) Intel's ICC turns on vectorizer a
tion will be larger and
>>>> larger. This is also a common practice in other compilers:
>>>>
>>>> 1) Intel's ICC turns on vectorizer at O2 by default and it has been
>>>> the case for many years;
>>>>
>>>> 2) Most recentl
n other compilers:
>>>
>>> 1) Intel's ICC turns on vectorizer at O2 by default and it has been
>>> the case for many years;
>>>
>>> 2) Most recently, LLVM turns it on for both O2 and Os.
>>>
>>>
>>> Here we propose moving
been
>> the case for many years;
>>
>> 2) Most recently, LLVM turns it on for both O2 and Os.
>>
>>
>> Here we propose moving vectorization from -O3 to -O2 in GCC. Three
>> main concerns about this change are: 1. Does vectorization greatly
>> increas
LLVM turns it on for both O2 and Os.
>
>
> Here we propose moving vectorization from -O3 to -O2 in GCC. Three
> main concerns about this change are: 1. Does vectorization greatly
> increase the generated code size? 2. How much performance can be
> improved? 3. Does vectorization increas
15 matches
Mail list logo