public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Kenneth Zadeck <zadeck@naturalbridge.com>
Cc: gcc-patches@gcc.gnu.org,  Ian Lance Taylor <iant@google.com>,
	 Uros Bizjak <ubizjak@gmail.com>
Subject: Re: [PATCH, rtl-optimization]: Fix PR rtl-optimization/33638
Date: Wed, 10 Oct 2007 12:19:00 -0000	[thread overview]
Message-ID: <200710101420.43418.ebotcazou@libertysurf.fr> (raw)
In-Reply-To: <200710092357.07520.ebotcazou@libertysurf.fr>

> > Another issue that this brings up is the code that deletes stores into
> > the frame pointer that die when the function returns.  I am now a little
> > worried that code may be also compromised.  If i am able to see the
> > store as being relative to the frame but there is some load whose
> > address has been stored in a register, i am screwed.
>
> This should be more or less an equivalent problem.

I was wrong.  Part of the problem stems from the confusion in dse.c about what
"stores into the frame" are.  They are defined as stores whose base is either
frame_pointer_rtx or hard_frame_pointer_rtx.  That's the right definition for 
the purpose quoted above and I think that these stores should be immune to 
the problem (address loaded into pseudo) because both frame_pointer_rtx and 
hard_frame_pointer_rtx are !rtx_varies_p, so canon_rtx will really return the 
canonicalized address.

Now, for const functions, we are not interested in these stores into the frame 
as defined above, we are interested in stores based on the *stack pointer*.

Quoting flow.c:

	  /* Non-constant calls clobber memory, constant calls do not
	     clobber memory, though they may clobber outgoing arguments
	     on the stack.  */
	  if (! CONST_OR_PURE_CALL_P (insn))
	    {
	      free_EXPR_LIST_list (&pbi->mem_set_list);
	      pbi->mem_set_list_len = 0;
	    }
	  else
	    invalidate_mems_from_set (pbi, stack_pointer_rtx);

And the solution to the canonicalization problem for those stores is already 
present in gcse.c:

static bool
store_killed_in_insn (const_rtx x, const_rtx x_regs, const_rtx insn, int 
after)
{
  const_rtx reg, base, note, pat;

  if (!INSN_P (insn))
    return false;

  if (CALL_P (insn))
    {
      /* A normal or pure call might read from pattern,
	 but a const call will not.  */
      if (! CONST_OR_PURE_CALL_P (insn) || pure_call_p (insn))
	return true;

      /* But even a const call reads its parameters.  Check whether the
	 base of some of registers used in mem is stack pointer.  */
      for (reg = x_regs; reg; reg = XEXP (reg, 1))
	{
	  base = find_base_term (XEXP (reg, 0));
	  if (!base
	      || (GET_CODE (base) == ADDRESS
		  && GET_MODE (base) == Pmode
		  && XEXP (base, 0) == stack_pointer_rtx))
	    return true;


(insn 1312 1310 1313 149 comunpack.f:61 (set (mem:SF (reg/f:SI 755) [0 S4 
A32])
        (reg:SF 646)) 66 {*movsf_1} (expr_list:REG_DEAD (reg:SF 646)
        (nil)))

(gdb) p debug_rtx(0x558bde40)
(reg/f:SI 755)
$19 = void
(gdb) p debug_rtx(find_base_term(0x558bde40))
(address:SI (reg/f:SI 7 sp))
$20 = void

-- 
Eric Botcazou

  reply	other threads:[~2007-10-10 12:19 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-08 12:14 Uros Bizjak
2007-10-08 12:35 ` [Bug rtl-optimization/33638] [4.3 regression]: wrong code with -fforce-addr Kenneth Zadeck
2007-10-09  6:01 ` [PATCH, rtl-optimization]: Fix PR rtl-optimization/33638 Ian Lance Taylor
2007-10-09  6:38   ` Eric Botcazou
2007-10-09  7:19     ` Ian Lance Taylor
2007-10-09 11:51       ` Kenneth Zadeck
2007-10-09 12:31         ` Uros Bizjak
2007-10-09 15:42           ` Ian Lance Taylor
2007-10-09 15:42         ` Ian Lance Taylor
2007-10-09 16:05           ` Kenneth Zadeck
2007-10-09 17:09             ` Ian Lance Taylor
2007-10-09 19:37       ` Eric Botcazou
2007-10-09 19:55         ` Kenneth Zadeck
2007-10-09 21:55           ` Eric Botcazou
2007-10-10 12:19             ` Eric Botcazou [this message]
2007-10-10 19:21               ` Eric Botcazou
2007-10-12 15:49                 ` Ian Lance Taylor
2007-10-12 17:10                   ` Eric Botcazou
2007-10-14 16:29                   ` Eric Botcazou
2007-10-15  5:47                     ` Ian Lance Taylor
2007-10-15  7:43                       ` Eric Botcazou
2007-10-10 10:45         ` 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=200710101420.43418.ebotcazou@libertysurf.fr \
    --to=ebotcazou@libertysurf.fr \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iant@google.com \
    --cc=ubizjak@gmail.com \
    --cc=zadeck@naturalbridge.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).