On 22/10/2015 15:15, "Alan Lawrence" wrote:
>Just one very small point...
>
>On 19/10/15 09:17, Alan Hayward wrote:
>
> > - if (check_reduction
> > - && (!commutative_tree_code (code) || !associative_tree_code
>(code)))
> > + if (check_reduction)
> > {
> > - if (dump_enabled_p
Just one very small point...
On 19/10/15 09:17, Alan Hayward wrote:
> - if (check_reduction
> - && (!commutative_tree_code (code) || !associative_tree_code (code)))
> + if (check_reduction)
> {
> - if (dump_enabled_p ())
> -report_vect_op (MSG_MISSED_OPTIMIZATION, def_st
On Mon, Oct 19, 2015 at 10:17 AM, Alan Hayward wrote:
>
>
>>On 30/09/2015 13:45, "Richard Biener" wrote:
>>
>>>On Wed, Sep 23, 2015 at 5:51 PM, Alan Hayward
>>>wrote:
On 18/09/2015 14:53, "Alan Hayward" wrote:
>
>
>On 18/09/2015 14:26, "Alan Lawrence" wrote:
>>>
On 30/09/2015 13:45, "Richard Biener" wrote:
>On Wed, Sep 23, 2015 at 5:51 PM, Alan Hayward
>wrote:
>>
>>
>> On 18/09/2015 14:53, "Alan Hayward" wrote:
>>
>>>
>>>
>>>On 18/09/2015 14:26, "Alan Lawrence" wrote:
>>>
On 18/09/15 13:17, Richard Biener wrote:
>
> Ok, I see.
>
On Wed, Sep 23, 2015 at 5:51 PM, Alan Hayward wrote:
>
>
> On 18/09/2015 14:53, "Alan Hayward" wrote:
>
>>
>>
>>On 18/09/2015 14:26, "Alan Lawrence" wrote:
>>
>>>On 18/09/15 13:17, Richard Biener wrote:
Ok, I see.
That this case is already vectorized is because it implements
On 18/09/2015 14:53, "Alan Hayward" wrote:
>
>
>On 18/09/2015 14:26, "Alan Lawrence" wrote:
>
>>On 18/09/15 13:17, Richard Biener wrote:
>>>
>>> Ok, I see.
>>>
>>> That this case is already vectorized is because it implements MAX_EXPR,
>>> modifying it slightly to
>>>
>>> int foo (int *a)
>>>
On 18/09/2015 14:26, "Alan Lawrence" wrote:
>On 18/09/15 13:17, Richard Biener wrote:
>>
>> Ok, I see.
>>
>> That this case is already vectorized is because it implements MAX_EXPR,
>> modifying it slightly to
>>
>> int foo (int *a)
>> {
>>int val = 0;
>>for (int i = 0; i < 1024; ++i)
>>
On 18/09/15 13:17, Richard Biener wrote:
Ok, I see.
That this case is already vectorized is because it implements MAX_EXPR,
modifying it slightly to
int foo (int *a)
{
int val = 0;
for (int i = 0; i < 1024; ++i)
if (a[i] > val)
val = a[i] + 1;
return val;
}
makes it no lo
On Tue, Sep 15, 2015 at 5:32 PM, Alan Hayward wrote:
>
>
> On 15/09/2015 13:09, "Richard Biener" wrote:
>
>>
>>Now comments on the patch itself.
>>
>>+ if (code == COND_EXPR)
>>+ *v_reduc_type = COND_REDUCTION;
>>
>>so why not simply use COND_EXPR instead of the new v_reduc_type?
>
> v
On 15/09/2015 13:09, "Richard Biener" wrote:
>
>Now comments on the patch itself.
>
>+ if (code == COND_EXPR)
>+ *v_reduc_type = COND_REDUCTION;
>
>so why not simply use COND_EXPR instead of the new v_reduc_type?
v_reduc_type is also dependant on check_reduction (which comes from
!n
On Thu, Sep 10, 2015 at 4:51 PM, Alan Hayward wrote:
> Hi,
> This patch (attached) adds support for vectorizing conditional expressions
> (PR 65947), for example:
>
> int condition_reduction (int *a, int min_v)
> {
> int last = 0;
> for (int i = 0; i < N; i++)
> if (a[i] < min_v)
> l
On Thu, Sep 10, 2015 at 4:51 PM, Alan Hayward wrote:
> Hi,
> This patch (attached) adds support for vectorizing conditional expressions
> (PR 65947), for example:
>
> int condition_reduction (int *a, int min_v)
> {
> int last = 0;
> for (int i = 0; i < N; i++)
> if (a[i] < min_v)
> l
On Fri, Sep 11, 2015 at 6:29 PM, Ramana Radhakrishnan
wrote:
>
Saying that all reductions have equivalent performance is unlikely to be
true for many platforms. On PowerPC, for example, a PLUS reduction has
very different cost from a MAX reduction. If the model isn't
fine-gra
On Mon, 2015-09-14 at 10:47 +0100, Alan Lawrence wrote:
> On 11/09/15 14:19, Bill Schmidt wrote:
> >
> > A secondary concern for powerpc is that REDUC_MAX_EXPR produces a scalar
> > that has to be broadcast back to a vector, and the best way to implement
> > it for us already has the max value in a
On 11/09/15 14:19, Bill Schmidt wrote:
A secondary concern for powerpc is that REDUC_MAX_EXPR produces a scalar
that has to be broadcast back to a vector, and the best way to implement
it for us already has the max value in all positions of a vector. But
that is something we should be able to f
>>> Saying that all reductions have equivalent performance is unlikely to be
>>> true for many platforms. On PowerPC, for example, a PLUS reduction has
>>> very different cost from a MAX reduction. If the model isn't
>>> fine-grained enough, let's please be aggressive about fixing it. I'm
>>> f
On Fri, 2015-09-11 at 16:28 +0100, Richard Sandiford wrote:
> Bill Schmidt writes:
> > On Fri, 2015-09-11 at 15:29 +0100, Richard Sandiford wrote:
> >> Ramana Radhakrishnan writes:
> >> > On Fri, Sep 11, 2015 at 2:19 PM, Bill Schmidt
> >> > wrote:
> >> >> Hi Alan,
> >> >>
> >> >> I probably wasn
Bill Schmidt writes:
> On Fri, 2015-09-11 at 15:29 +0100, Richard Sandiford wrote:
>> Ramana Radhakrishnan writes:
>> > On Fri, Sep 11, 2015 at 2:19 PM, Bill Schmidt
>> > wrote:
>> >> Hi Alan,
>> >>
>> >> I probably wasn't clear enough. The implementation in the vectorizer is
>> >> fine and I'm
On Fri, 2015-09-11 at 15:29 +0100, Richard Sandiford wrote:
> Ramana Radhakrishnan writes:
> > On Fri, Sep 11, 2015 at 2:19 PM, Bill Schmidt
> > wrote:
> >> Hi Alan,
> >>
> >> I probably wasn't clear enough. The implementation in the vectorizer is
> >> fine and I'm not asking that to change per
Ramana Radhakrishnan writes:
> On Fri, Sep 11, 2015 at 2:19 PM, Bill Schmidt
> wrote:
>> Hi Alan,
>>
>> I probably wasn't clear enough. The implementation in the vectorizer is
>> fine and I'm not asking that to change per target. What I'm objecting
>> to is the equivalence between a REDUC_MAX_E
On Fri, Sep 11, 2015 at 2:19 PM, Bill Schmidt
wrote:
> Hi Alan,
>
> I probably wasn't clear enough. The implementation in the vectorizer is
> fine and I'm not asking that to change per target. What I'm objecting
> to is the equivalence between a REDUC_MAX_EXPR and a cost associated
> with vec_to
Hi Alan,
I probably wasn't clear enough. The implementation in the vectorizer is
fine and I'm not asking that to change per target. What I'm objecting
to is the equivalence between a REDUC_MAX_EXPR and a cost associated
with vec_to_scalar. This assumes that the back end will implement a
REDUC_M
Hi Bill,
I’d be a bit worried about asking the backend for the cost of a
COND_REDUCTION, as that will rely on the backend understanding the
implementation the vectorizer is using - every time the vectorizer
changed, the backends would need to be updated too. I’m hoping soon to get
together a patch
Hi Alan,
The cost modeling of the epilogue code seems pretty target-specific ("An
EQ stmt and an AND stmt, reduction of the max index and a reduction of
the found values, a broadcast of the max value," resulting in two
vector_stmts, one vec_to_scalar, and two scalar_to_vecs). On powerpc,
this wil
Hi,
This patch (attached) adds support for vectorizing conditional expressions
(PR 65947), for example:
int condition_reduction (int *a, int min_v)
{
int last = 0;
for (int i = 0; i < N; i++)
if (a[i] < min_v)
last = a[i];
return last;
}
To do this the loop is vectorised to create
25 matches
Mail list logo
