public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Edelsohn <dje.gcc@gmail.com>
To: Jeff Law <law@redhat.com>, Alexander Fomin <afomin.mailbox@gmail.com>
Cc: Richard Biener <rguenther@suse.de>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
		Igor Zamyatin <izamyatin@gmail.com>
Subject: Re: [PATCH] PR rtl-optimization/64081: Enable RTL loop unrolling for duplicated exit blocks and back edges.
Date: Sat, 06 Feb 2016 19:08:00 -0000	[thread overview]
Message-ID: <CAGWvny=sgJWJxGwqe3=Qxm8L04SyfMVyO7jvGCKt3qG3ofWa8A@mail.gmail.com> (raw)
In-Reply-To: <56B505B5.8020106@redhat.com>

On Fri, Feb 5, 2016 at 3:27 PM, Jeff Law <law@redhat.com> wrote:
> On 02/05/2016 06:43 AM, Alexander Fomin wrote:
>>
>> Hi!
>>
>> Some kind of this patch was submitted about a year ago by Igor
>> Zamyatin. It's an attempt to fix PR rtl-optimization/64081 by enabling
>> RTL loop unrolling for duplicated exit blocks and back edges.
>>
>> At the time it caused AIX bootstrap failure, but now it's OK according
>> to David's testing. I've also bootstrapped and regtested it on
>> x86_64-linux-gnu.
>>
>> Is it still OK for trunk now, or you consider this v7 stuff?
>> Anyway, it's a regression.
>>
>> Thanks,
>> Alexander
>> ---
>> gcc/
>>
>>         PR rtl-optimization/64081
>>         * loop-iv.c (def_pred_latch_p): New function.
>>         (latch_dominating_def): Allow specific cases with non-single
>>         definitions.
>>         (iv_get_reaching_def): Likewise.
>>         (check_complex_exit_p): New function.
>>         (check_simple_exit): Use check_complex_exit_p to allow certain
>> cases
>>         with exits not executing on any iteration.
>>
>> gcc/testsuite
>>
>>         PR rtl-optimization/64081
>>         * gcc.dg/pr64081.c: New test.
>
> Normally I'd say that if it was approved before, then it's still good to go
> since there haven't been major conceptual changes in this code since the
> patch was originally written and now.
>
> However, in this instance the patch had been reported to cause problems on
> AIX, problems that we can't reproduce now -- which makes me want to be more
> cautious.  Was it a problem with the patch, or some other latent issue -- we
> don't know at this point.
>
> So I think the way to go is to apply this patch on top of r219827 where it
> caused the AIX failure.  Then bootstrap on aix and determine the root cause
> of of the AIX bootstrap failure.  If it's this patch, then update the patch
> as needed.  If the patch is just exposing a latent bug elsewhere, we should
> evaluate whether or not that latent but has been fixed or not before
> applying this fix to the trunk.
>
> It's considerably more work, but ISTM it's the right thing to do.

I'm on the fence about this patch.  I definitely don't think that it
should be merged for GCC 6.

If the patch were to be proposed during Stage 1 for GCC 7 and had not
caused bootstrap problems for AIX, no one would have any question.

The problem is we don't know if the patch exposed a latent bug that
independently was fixed after the patch was reverted or if the patch
still contains a bug that has been rendered latent by another change.

Another approach to track down the cause would be to bisect which
patch fixed the bootstrap failure if the patch had not been reverted.

I agree with Jeff that a statement that "the original patch magically
works now" is not a good justification for merging it -- at least not
for GCC 6.

Thanks, David

  reply	other threads:[~2016-02-06 19:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-05 13:44 Alexander Fomin
2016-02-05 20:27 ` Jeff Law
2016-02-06 19:08   ` David Edelsohn [this message]
2016-02-06 19:42     ` Jeff Law
2016-02-06 20:00       ` Alexander Fomin
2016-02-10 11:34       ` Alexander Fomin
2016-02-10 12:32         ` Bernd Schmidt

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='CAGWvny=sgJWJxGwqe3=Qxm8L04SyfMVyO7jvGCKt3qG3ofWa8A@mail.gmail.com' \
    --to=dje.gcc@gmail.com \
    --cc=afomin.mailbox@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=izamyatin@gmail.com \
    --cc=law@redhat.com \
    --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).