From: "Bin.Cheng" <amker.cheng@gmail.com>
To: Tom de Vries <Tom_deVries@mentor.com>
Cc: Richard Biener <rguenther@suse.de>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [parloops, PR83126], Use cached affine_ivs canonicalize_loop_ivs
Date: Wed, 21 Mar 2018 15:38:00 -0000 [thread overview]
Message-ID: <CAHFci28DMBeGYHbbAMwCpO7Qcnkp--Lqh5md8L0LE_7J4JyiYA@mail.gmail.com> (raw)
In-Reply-To: <4b1d8bca-81b0-16e1-6df9-6bc76fa9d9a7@mentor.com>
On Wed, Mar 21, 2018 at 3:06 PM, Tom de Vries <Tom_deVries@mentor.com> wrote:
> On 03/12/2018 01:14 PM, Richard Biener wrote:
>>
>> On Thu, 22 Feb 2018, Tom de Vries wrote:
>>
>>> Hi,
>>>
>>> this patch fixes an ICE in the parloops pass.
>>>
>>> The ICE (when compiling the test-case in attached patch) follows from the
>>> fact
>>> that here in gen_parallel_loop the call to canonicalize_loop_ivs fails to
>>> "base all the induction variables in LOOP on a single control one":
>>> ...
>>> /* Base all the induction variables in LOOP on a single control one.*/
>>> canonicalize_loop_ivs (loop, &nit, true);
>>> ...
>>>
>>> This is caused by the fact that for one of the induction variables,
>>> simple_iv
>>> no longer returns true (as was the case at the start of
>>> gen_parallel_loop).
>>> This seems to be triggered by the fact that during loop_version we call
>>> scev_reset (although I'm not sure why when recalculating scev info we're
>>> not
>>> reaching the same conclusion as before).
>>
>> I guess the real reason is that canonicalize_loop_ivs calls
>> create_iv first which in the parloop case with bump-in-latch true
>> and then incrementally re-writes PHIs, eventually wrecking other
>> PHIs SCEV. In this case the 2nd PHIs evolution depends on the
>> first one but the rewritten ones depend on the new IV already.
>>
>> So the better fix (maybe not 100% enough) would be to re-organize
>> canonicalize_loop_ivs to first do analysis of all PHIs and then
>> rewrite them all.
>>
>
> Focusing on the re-organize first, is this sort of what you had in mind?
FYI, we have multiple interfaces manipulating on IVs, sometimes in a similar
way. An example would be create_canonical_iv in tree-ssa-loop-ivcanon.c.
One proposal for discussion is to refactor such interfaces and put them in a
single source file, like tree-ssa-loop-ivopts. For example of
create_canonical_iv,
it can be removed by simply adding the corresponding candidate in IVOPTs.
Thanks,
bin
>
> Bootstrapped and reg-tested on x86_64.
>
> Thanks,
> - Tom
next prev parent reply other threads:[~2018-03-21 15:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-22 12:09 Tom de Vries
2018-03-12 12:14 ` Richard Biener
2018-03-21 10:38 ` Tom de Vries
2018-03-21 10:48 ` Richard Biener
2018-03-21 15:31 ` Tom de Vries
2018-03-21 15:38 ` Bin.Cheng [this message]
2018-03-21 15:49 ` Richard Biener
2018-03-22 15:33 ` Tom de Vries
2018-03-22 15:48 ` Tom de Vries
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=CAHFci28DMBeGYHbbAMwCpO7Qcnkp--Lqh5md8L0LE_7J4JyiYA@mail.gmail.com \
--to=amker.cheng@gmail.com \
--cc=Tom_deVries@mentor.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rguenther@suse.de \
/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).