From: Jakub Jelinek <jakub@redhat.com>
To: Eric Botcazou <ebotcazou@adacore.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Fix combiner (PRs rtl-optimization/46034, rtl-optimization/46212, rtl-optimization/46248)
Date: Tue, 02 Nov 2010 20:51:00 -0000 [thread overview]
Message-ID: <20101102204817.GJ29412@tyan-ft48-01.lab.bos.redhat.com> (raw)
In-Reply-To: <201011022127.29192.ebotcazou@adacore.com>
On Tue, Nov 02, 2010 at 09:27:29PM +0100, Eric Botcazou wrote:
> > There are two issues, one is that the earlier
> > newpat = subst (newpat, i0dest, i0src, ...);
> > might have (but not necessarily) have changed i1src and so when i1dest
> > is first replaced with i1src that way modified and then i0dest is replaced
> > with i0src, the replacements are already wrong and as testcases show
> > self-referential.
>
> FWIW I also debugged this (and spotted a pasto in the 4-insn combiner patch
> that I'll fix after your fixes, patch attached). I also roughly came up with:
>
> + /* Following subst may modify i1src, make a copy of it
> + before it is for added_sets_2 handling if needed. */
> + if (added_sets_2
> + && i0dest_in_i0src
> + && i0_feeds_i1_n
> + && (i1_feeds_i2_n || i0_feeds_i2_n))
> + i1src_copy = copy_rtx (i1src);
>
> but why not just
>
> if (i0_feeds_i1_n && added_sets_2 && i1_feeds_i2_n)
>
> i.e. make a copy if substituting I0 will clobber I1SRC and I1SRC will be re-
> substituted in I2PAT?
I think you are right, if !i1_feeds_i2_n then the copy is not needed,
because it will not be used. If !i0dest_in_i0src, I think
the copy is not strictily needed, because it shouldn't matter whether
i0dest is replaced with i0src just once or more than once, but if you
prefer the if (i0_feeds_i1_n && added_sets_2 && i1_feeds_i2_n)
condition, I can bootstrap/regtest it with that.
>
> > The other issue is that if we are to apply more than
> > one substitution on i2pat and i0dest_in_i0src, then we need to pass
> > 1 as last argument to the first subst in order to avoid unwanted
> > rtl sharing (which again can lead to self-referential rtl).
> > Another issue is that if all of i0_feeds_i2_n, i0_feeds_i1_n and
> > i1_feeds_i2_n is true, then we'd be substituting i0dest with i0src
> > in i2pat twice.
>
> This part looks OK to me.
>
>
> * combine.c (try_combine): Fix formatting issues and a pasto.
Yeah, the
> - newpat = subst (newpat, i0dest, i0src, 0,
> - i0_feeds_i1_n && i0dest_in_i0src);
> + newpat = subst (newpat, i0dest, i0src, 0, 0);
is what I came across too and it surprised me, but I decided it
doesn't break anything, just is inefficient. But you're right it is better
to fix it to make the code more readable.
Jakub
next prev parent reply other threads:[~2010-11-02 20:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-01 21:28 Jakub Jelinek
2010-11-02 20:36 ` Eric Botcazou
2010-11-02 20:51 ` Jakub Jelinek [this message]
2010-11-02 21:04 ` Eric Botcazou
2010-11-03 9:17 ` Jakub Jelinek
2010-11-03 18:03 ` Eric Botcazou
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=20101102204817.GJ29412@tyan-ft48-01.lab.bos.redhat.com \
--to=jakub@redhat.com \
--cc=ebotcazou@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
/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).