On Mon, 11 Dec 2017, Jakub Jelinek wrote:
> On Mon, Dec 11, 2017 at 06:00:11PM +0100, Kilian Verhetsel wrote:
> > Jakub Jelinek writes:
> > > Of course it can be done efficiently, what we care most is that the body
> > > of
> > > the vectorized loop is efficient.
> >
> > That's fair, I was look
On Mon, Dec 11, 2017 at 06:00:11PM +0100, Kilian Verhetsel wrote:
> Jakub Jelinek writes:
> > Of course it can be done efficiently, what we care most is that the body of
> > the vectorized loop is efficient.
>
> That's fair, I was looking at the x86 assembly being generated when a single
> vector
On Mon, Dec 11, 2017 at 06:00:11PM +0100, Kilian Verhetsel wrote:
> Jakub Jelinek writes:
> > Of course it can be done efficiently, what we care most is that the body of
> > the vectorized loop is efficient.
>
> That's fair, I was looking at the x86 assembly being generated when a single
> vector
Jakub Jelinek writes:
> Of course it can be done efficiently, what we care most is that the body of
> the vectorized loop is efficient.
That's fair, I was looking at the x86 assembly being generated when a single
vectorized iteration was enough (because that is the context in which I
first encou
On Mon, Dec 11, 2017 at 02:11:34PM +0100, Jakub Jelinek wrote:
> Thanks, it applies cleanly now
> > + else if ((STMT_VINFO_VEC_REDUCTION_TYPE (stmt_info) == COND_REDUCTION
> > + || (STMT_VINFO_VEC_REDUCTION_TYPE (stmt_info)
> > + == INTEGER_INDUC_COND_REDUCTION))
> > + && redu
On Mon, Dec 11, 2017 at 11:56:55AM +0100, Kilian Verhetsel wrote:
> Jakub Jelinek writes:
> > As it doesn't apply, I can't easily check what the patch generates
> > on the PR80631 testcases vs. my thoughts on that; though, if it emits
> > something more complicated for the simple cases, perhaps we
Hello,
Jakub Jelinek writes:
> As it doesn't apply, I can't easily check what the patch generates
> on the PR80631 testcases vs. my thoughts on that; though, if it emits
> something more complicated for the simple cases, perhaps we could improve
> those (not handle it like COND_REDUCTION, but in
Hi!
What is going on with this patch, will anybody commit it?
This is also http://gcc.gnu.org/PR80631 apparently.
The patch doesn't apply cleanly to current trunk due to the
reduc_code -> reduc_fn changes.
As it doesn't apply, I can't easily check what the patch generates
on the PR80631 testcas
On Thu, Nov 23, 2017 at 10:51 AM, Alan Hayward wrote:
>
>> On 22 Nov 2017, at 16:57, Kilian Verhetsel
>> wrote:
>>
>>
>> Thank you both for your comments.
>>
>> I have added the check to ensure the index vector won't cause an
>> overflow. I also added tests to the testsuite in order to check tha
> On 22 Nov 2017, at 16:57, Kilian Verhetsel
> wrote:
>
>
> Thank you both for your comments.
>
> I have added the check to ensure the index vector won't cause an
> overflow. I also added tests to the testsuite in order to check that the
> loop is vectorized for UINT_MAX - 1 iterations but no
Thank you both for your comments.
I have added the check to ensure the index vector won't cause an
overflow. I also added tests to the testsuite in order to check that the
loop is vectorized for UINT_MAX - 1 iterations but not UINT_MAX
iterations. I was not able to write code that triggers
INTEGE
On Wed, Nov 22, 2017 at 12:01 PM, Alan Hayward wrote:
>
>> On 22 Nov 2017, at 09:14, Richard Biener wrote:
>>
>> On Tue, Nov 21, 2017 at 5:43 PM, Kilian Verhetsel
>> wrote:
>>>
This is PR81179 I think, please mention that in the changelog.
>>>
>>> Correct, my bad for missing that.
>>>
> On 22 Nov 2017, at 09:14, Richard Biener wrote:
>
> On Tue, Nov 21, 2017 at 5:43 PM, Kilian Verhetsel
> wrote:
>>
>>> This is PR81179 I think, please mention that in the changelog.
>>
>> Correct, my bad for missing that.
>>
>>> This unconditionally pessimizes code even if there is no valid
On Tue, Nov 21, 2017 at 5:43 PM, Kilian Verhetsel
wrote:
>
>> This is PR81179 I think, please mention that in the changelog.
>
> Correct, my bad for missing that.
>
>> This unconditionally pessimizes code even if there is no valid index
>> zero, right?
>
> Almost, since for a loop such as:
>
> #
> On 21 Nov 2017, at 16:43, Kilian Verhetsel
> wrote:
>
>
>> This is PR81179 I think, please mention that in the changelog.
>
> Correct, my bad for missing that.
>
>> This unconditionally pessimizes code even if there is no valid index
>> zero, right?
>
> Almost, since for a loop such as:
>
> This is PR81179 I think, please mention that in the changelog.
Correct, my bad for missing that.
> This unconditionally pessimizes code even if there is no valid index
> zero, right?
Almost, since for a loop such as:
#define OFFSET 1
unsigned int find(const unsigned int *a, unsigned int
On Tue, Nov 21, 2017 at 12:35 PM, Kilian Verhetsel
wrote:
>
> Hi,
>
> When translating conditional reductions based on integer induction, the
> compiler uses the value zero to indicate the absence of any matches: if
> the index of the last match is still zero at the end of the loop, the
> default
Hi,
When translating conditional reductions based on integer induction, the
compiler uses the value zero to indicate the absence of any matches: if
the index of the last match is still zero at the end of the loop, the
default value is returned. The problem with this approach is that this
default
18 matches
Mail list logo
