From: Richard Biener <richard.guenther@gmail.com>
To: Tom de Vries <Tom_deVries@mentor.com>
Cc: Sebastian Pop <sebpop@gmail.com>,
"gcc-patches@gnu.org" <gcc-patches@gnu.org>
Subject: Re: [PATCH] Don't allow unsafe reductions in graphite
Date: Thu, 23 Jul 2015 10:51:00 -0000 [thread overview]
Message-ID: <CAFiYyc0Nr_dMX9Yy+inCohAaS0iopHghzxYSf4XiAPe7mza9Dw@mail.gmail.com> (raw)
In-Reply-To: <55AFBE25.5020508@mentor.com>
On Wed, Jul 22, 2015 at 6:00 PM, Tom de Vries <Tom_deVries@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.guenther@gmail.com> wrote:
>>>
>>> >On Tue, Jul 21, 2015 at 8:42 PM, Sebastian Pop<sebpop@gmail.com> wrote:
>>>>
>>>> >>Tom de Vries wrote:
>>>>>
>>>>> >>>Fix reduction safety checks
>>>>> >>>
>>>>> >>> * graphite-sese-to-poly.c (is_reduction_operation_p): Limit
>>>>> >>> flag_associative_math to SCALAR_FLOAT_TYPE_P. Honour
>>>>> >>> TYPE_OVERFLOW_TRAPS and TYPE_OVERFLOW_WRAPS for
>>>>> >>> INTEGRAL_TYPE_P.
>>>>> >>> Only allow wrapping fixed-point otherwise.
>>>>> >>> (build_poly_scop): Always call
>>>>> >>> rewrite_commutative_reductions_out_of_ssa.
>>>>
>>>> >>
>>>> >>The changes to graphite look good to me.
>>>
>>> >
>>> >+ if (SCALAR_FLOAT_TYPE_P (type))
>>> >+ return flag_associative_math;
>>> >+
>>> >
>>> >why only scalar floats?
>
>
> Copied from the conditions in vect_is_simple_reduction_1.
>
>>> >Please use FLOAT_TYPE_P.
>
> Done.
>
>>> >
>>> >+ if (INTEGRAL_TYPE_P (type))
>>> >+ return (!TYPE_OVERFLOW_TRAPS (type)
>>> >+ && TYPE_OVERFLOW_WRAPS (type));
>>> >
>>> >it cannot both wrap and trap thus TYPE_OVERFLOW_WRAPS is enough.
>>> >
>
>
> Done.
>
>>> >I'm sure you'll disable quite some parallelization this way... (the
>>> >routine is modeled after
>>> >the vectorizers IIRC, so it would be affected as well). Yeah - I see
>>> >you modify autopar
>>> >testcases.
>
>
> I now split up the patch, this bit only relates to graphite, so no autopar
> testcases are affected.
>
>>> >Please instead XFAIL the existing ones and add variants
>>> >with unsigned
>>> >reductions. Adding -fwrapv isn't a good solution either.
>
>
> Done.
>
>>> >
>>> >Can you think of a testcase that breaks btw?
>>> >
>
>
> If you mean a testcase that fails to execute properly with the fix, and
> executes correctly with the fix, then no. The problem this patch is trying
> to fix, is that we assume wrapping overflow without fwrapv. In order to run
> into a runtime failure, we need a target that does not do wrapping overflow
> without fwrapv.
>
>>> >The "proper" solution (see other passes) is to rewrite the reduction
>>> >to a wrapping
>>> >one (cast to unsigned for the reduction op).
>>> >
>
>
> Right.
>
>>> >+ return (FIXED_POINT_TYPE_P (type)
>>> >+ && FIXED_POINT_TYPE_OVERFLOW_WRAPS_P (type));
>>> >
>>> >why?
>
>
> Again, copied from the conditions in vect_is_simple_reduction_1.
>
>>> > Simply return false here instead?
>
> Done.
>
>
> [ Btw, looking at associative_tree_code, I realized that the
> overflow checking is only necessary for PLUS_EXPR and MULT_EXPR:
> ...
> switch (code)
> {
> case BIT_IOR_EXPR:
> case BIT_AND_EXPR:
> case BIT_XOR_EXPR:
> case PLUS_EXPR:
> case MULT_EXPR:
> case MIN_EXPR:
> case MAX_EXPR:
> return true;
> ...
>
> The other operators cannot overflow to begin with. My guess is that it's
> better to leave this for a trunk-only follow-up patch.
> ]
>
> Currently bootstrapping and reg-testing on x86_64.
>
> OK for trunk?
>
> OK 5 and 4.9 release branches?
Ok if Sebastian is fine with it.
Richard.
> Thanks,
> - Tom
>
next prev parent reply other threads:[~2015-07-23 10:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-15 22:18 [RFC, PR66873] Use graphite for parloops Tom de Vries
2015-07-16 8:48 ` Richard Biener
2015-07-16 10:25 ` Thomas Schwinge
2015-07-16 10:28 ` Richard Biener
2015-07-16 10:41 ` Richard Biener
2015-07-26 22:54 ` Tom de Vries
2015-07-27 5:41 ` Sebastian Pop
2015-07-16 11:41 ` Tom de Vries
2015-07-20 18:53 ` Sebastian Pop
2015-07-21 0:22 ` Tom de Vries
2015-07-20 18:54 ` Sebastian Pop
2015-07-21 5:59 ` Tom de Vries
2015-07-21 14:35 ` Tom de Vries
2015-07-21 19:08 ` Sebastian Pop
2015-07-22 11:02 ` Richard Biener
2015-07-22 11:18 ` Richard Biener
2015-07-22 16:04 ` [PATCH] Don't allow unsafe reductions in graphite Tom de Vries
2015-07-23 10:51 ` Richard Biener [this message]
2015-07-24 20:37 ` Sebastian Pop
2015-07-25 11:41 ` Tom de Vries
2015-07-22 16:38 ` [PATCH] Check TYPE_OVERFLOW_WRAPS for parloops reductions Tom de Vries
2015-07-23 10:54 ` Richard Biener
2015-07-24 10:43 ` [committed] Remove xfail in autopar/uns-outer-4.c Tom de Vries
2015-07-24 11:54 ` [PATCH] Add FIXED_POINT_TYPE_OVERFLOW_WRAPS_P Tom de Vries
2015-07-22 15:33 ` [PATCH] Document ftrapv/fwrapv interaction Tom de Vries
2015-07-23 10:39 ` Richard Biener
2015-07-23 10:42 ` Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFiYyc0Nr_dMX9Yy+inCohAaS0iopHghzxYSf4XiAPe7mza9Dw@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=Tom_deVries@mentor.com \
--cc=gcc-patches@gnu.org \
--cc=sebpop@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).