public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>,
	Richard Biener <rguenther@suse.de>,
	Eric Botcazou <ebotcazou@adacore.com>,
	Uros Bizjak <ubizjak@gmail.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Check for sp push/pop insns in reg_set_p (PR target/79430)
Date: Thu, 27 Apr 2017 17:38:00 -0000	[thread overview]
Message-ID: <9038c2be-280d-7db2-8fa2-7320e2324bb2@redhat.com> (raw)
In-Reply-To: <20170427073250.GW1809@tucnak>

On 04/27/2017 01:32 AM, Jakub Jelinek wrote:
> Hi!
> 
> As mentioned in the PR and can be seen on the testcase (too large for
> testsuite, with lots of delta reduction I got 48KB *.f90 file still using
> a dozen of modules), we miscompile it because we have mem(sp+64) memory
> (what %st is loaded from) and are checking whether it is safe to move
> earlier in the insn stream, and modified_between_p tells us it is, except
> there is a stack pop instruction (i.e. sp autoinc).
> And sp autoinc is apparently special in GCC:
>        /* There are no REG_INC notes for SP.  */
Right.  It's been the source of numerous problems through the years. 
One could argue that we should just bite the bullet and add them.  The 
cost can't be that high and it'd avoid these kinds of problems in the 
future and allow for some code cleanups as well.

We could probably scan the IL at the end of auto-inc-dec.c to add the 
missing notes.

I thought I saw a comment once which indicates the rationale behind not 
including REG_INC notes for pushes/pops, but I can't find it anymore.

> 
> The following patch handles that, plus then undoes that in ix86_agi_dependent
> where from what I understood we want the previous behavior - push, pop and
> call modifications of SP don't cause AGI stalls for addresses that have
> SP base (SP can't appear as index).
> 
> Not really sure about the == stack_pointer_rtx vs.
> REG_P () && REGNO () == STACK_POINTER_REGNUM, there is lots of code that
> just uses pointer comparisons and others that check REGNO, as an example
> of the former e.g. push/pop_operand.  So, is SP always shared, or can there
> be other REGs with SP regno?
SP is supposed to be shared, you should be able to compare against 
stack_pointer_rtx.


> 
> Other than the ix86_agi_dependent which in my stats was the single case
> that hit this difference, I've seen it making a difference e.g. in ifcvt
> decisions, but at least the cases I've debugged didn't end up in any code
> generation changes.  E.g. both x86_64 and i686 libstdc++.so.6 and
> libgo.so.11 as the two largest shared libraries built during bootstrap
> are identical without/with this patch (objdump -dr is identical that is).
> While without the config/i386/i386.c changes there were tons of differences.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2017-04-27  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR target/79430
> 	* rtlanal.c (reg_set_p): If reg is a stack_pointer_rtx, also
> 	check for stack push/pop autoinc.
> 	* config/i386/i386.c (ix86_agi_dependent): Return false
> 	if the only reason why modified_in_p returned true is that
> 	addr is SP based and set_insn is a push or pop.
THe rtlanal.c changes are fine by me.  Uros should chime in on the x86 
specific bits.

Jeff

  reply	other threads:[~2017-04-27 16:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-27  8:04 Jakub Jelinek
2017-04-27 17:38 ` Jeff Law [this message]
2017-05-01  9:24   ` Uros Bizjak

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=9038c2be-280d-7db2-8fa2-7320e2324bb2@redhat.com \
    --to=law@redhat.com \
    --cc=ebotcazou@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=rguenther@suse.de \
    --cc=ubizjak@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).