On Wed, Jul 22, 2015 at 6:13 PM, Tom de Vries <tom_devr...@mentor.com> wrote:
> [ was: Re: [RFC, PR66873] Use graphite for parloops ]
>
> On 22/07/15 13:02, Richard Biener wrote:
>>
>> On Wed, Jul 22, 2015 at 1:01 PM, Richard Biener
>> <richard.guent...@gmail.com> wrote:
>>>
>>> On Tue, Jul 21, 2015 at 8:42 PM, Sebastian Pop <seb...@gmail.com> wrote:
>>>>
>>>> Tom de Vries wrote:
>>>>>
>>>>> Fix reduction safety checks
>>>>>
>
>>> diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
>>> index 9145dbf..e014be2 100644
>>> --- a/gcc/tree-vect-loop.c
>>> +++ b/gcc/tree-vect-loop.c
>>> @@ -2613,16 +2613,30 @@ vect_is_simple_reduction_1 (loop_vec_info
>>> loop_info, gimple phi,
>>> "reduction: unsafe fp math optimization: ");
>>> return NULL;
>>> }
>>> - else if (INTEGRAL_TYPE_P (type) && TYPE_OVERFLOW_TRAPS (type)
>>> - && check_reduction)
>>> + else if (INTEGRAL_TYPE_P (type) && check_reduction)
>>> {
>>> ...
>>>
>>> You didn't need to adjust any testcases?
>>> That's probably because the
>>> checking above is
>>> not always executed (see PR66623 for a related testcase). The code
>>> needs refactoring.
>>> And we need a way-out, that is, we do _not_ want to not vectorize
>>> signed reductions.
>>> So you need to fix code generation instead.
>>
>>
>> Btw, for the vectorizer the current "trick" is that nobody takes advantage
>> about
>> overflow undefinedness for vector types.
>>
>
> AFAIU, you're saying here that there's no current bug related to assuming
> wrapping overflow in the vectorizer?
Well - TYPE_OVERFLOW_UNDEFINED will happily return true for
vector integer types but nothing I know will exploit that (bogus) knowledge.
And I'd rather change the reporting of TYPE_OVERFLOW_UNDEFINED here
as the C standard doesn't have vector types and the middle-end cannot
distinguish
user-written code (via intrinsics now using the generic vector GCC
language extension)
from compiler-generated code.
Similar for _Complex integer types (also a GCC extension?).
> I've updated the patch accordingly, so we only bother about
> TYPE_OVERFLOW_WRAPS for parloops reductions.
>
> Currently bootstrapping and reg-testing on x86_64.
>
> OK for trunk?
Ok.
Thanks,
Richard.
> Thanks,
> - Tom
>
