public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Eric Botcazou <ebotcazou@adacore.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org, Alexandre Oliva <aoliva@redhat.com>
Subject: Re: [patch] Fix var-tracking with dynamic stack realignment on x86
Date: Tue, 24 May 2011 12:21:00 -0000	[thread overview]
Message-ID: <201105241259.57887.ebotcazou@adacore.com> (raw)
In-Reply-To: <20110523164658.GB17079@tyan-ft48-01.lab.bos.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]

> Here is an alternative, almost completely untested, patch, which
> uses DW_OP_fbreg <N> for the arguments of dynamically realigned functions.
> draptest.c now works...

Thanks for the tip.  I completely overlooked this CFA-based machinery and now 
agree that it's the most sensible approach.  For my defense, I would point out 
that it's quite lightly documented. :-)  I've attached a patch that adds a 
blurb about it (as well as contains the fp_cfa_offset adjustment we both have 
in our patches).  I'll install it as obvious if you don't have any objection.

Now on to a few questions:

> 2011-05-23  Jakub Jelinek  <jakub@redhat.com>
>
> 	* var-tracking.c (vt_add_function_parameter): Remap incoming
> 	MEMs with crtl->args.internal_arg_pointer based address
> 	if stack_realign_drap to arg_pointer_rtx.
> 	(vt_init_cfa_base): Add equate argument, don't equate cfa_base_rtx
> 	to hfp/sp if it is false.
> 	(vt_initialize): Adjust vt_init_cfa_base callers, don't call
> 	vt_init_cfa_base if frame_pointer_needed, but fp_cfa_offset is -1,
> 	set fp_cfa_offset to -1 if fp/argp hasn't been eliminated.

Why setting CFA_BASE_RTX here?  The remapping in vt_add_function_parameter 
doesn't seem to need it.  Is that necessary so that the processing of MEMs is 
short-circuited elsewhere?  If so, would this be correct in the whole function 
given that the MEMs aren't adjusted in this case (i.e. compute_cfa_pointer is 
never called)?


	* var-tracking.c (compute_cfa_pointer): Adjust head comment.
	(vt_initialize):  Set PROLOGUE_BB unconditionally.
	Add block comment about CFA_BASE_RTX machinery.
	Reset FP_CFA_OFFSET to -1 on all invalid paths.
	Call vt_init_cfa_base only if FP_CFA_OFFSET isn't equal to -1.


-- 
Eric Botcazou

[-- Attachment #2: p.diff --]
[-- Type: text/x-diff, Size: 2282 bytes --]

Index: var-tracking.c
===================================================================
--- var-tracking.c	(revision 174058)
+++ var-tracking.c	(working copy)
@@ -705,7 +705,8 @@ vt_stack_adjustments (void)
 static rtx cfa_base_rtx;
 static HOST_WIDE_INT cfa_base_offset;
 
-/* Compute a CFA-based value for the stack pointer.  */
+/* Compute a CFA-based value for an ADJUSTMENT made to stack_pointer_rtx
+   or hard_frame_pointer_rtx.  */
 
 static inline rtx
 compute_cfa_pointer (HOST_WIDE_INT adjustment)
@@ -8664,7 +8665,7 @@ vt_init_cfa_base (void)
 static bool
 vt_initialize (void)
 {
-  basic_block bb, prologue_bb = NULL;
+  basic_block bb, prologue_bb = single_succ (ENTRY_BLOCK_PTR);
   HOST_WIDE_INT fp_cfa_offset = -1;
 
   alloc_aux_for_blocks (sizeof (struct variable_tracking_info_def));
@@ -8722,6 +8723,15 @@ vt_initialize (void)
 
   CLEAR_HARD_REG_SET (argument_reg_set);
 
+  /* In order to shield ourselves from adjustments to the stack pointer or to
+     the hard frame pointer that aren't meant to change the base location of
+     variables, we're going to rewrite MEMs based on them into MEMs based on
+     the CFA by de-eliminating stack_pointer_rtx or hard_frame_pointer_rtx to
+     the virtual CFA pointer frame_pointer_rtx resp. arg_pointer_rtx.  We can
+     do this either when there is no frame pointer in the function and stack
+     adjustments are consistent for all basic blocks or when there is a frame
+     pointer and no stack realignment.  In any case, we first have to check
+     that frame_pointer_rtx resp. arg_pointer_rtx has been eliminated.  */
   if (!frame_pointer_needed)
     {
       rtx reg, elim;
@@ -8764,10 +8774,11 @@ vt_initialize (void)
 	    }
 	  if (elim != hard_frame_pointer_rtx)
 	    fp_cfa_offset = -1;
-	  else
-	    prologue_bb = single_succ (ENTRY_BLOCK_PTR);
 	}
+      else
+	fp_cfa_offset = -1;
     }
+
   if (frame_pointer_needed)
     {
       rtx insn;
@@ -8870,7 +8881,8 @@ vt_initialize (void)
 		  if (bb == prologue_bb
 		      && hard_frame_pointer_adjustment == -1
 		      && RTX_FRAME_RELATED_P (insn)
-		      && fp_setter (insn))
+		      && fp_setter (insn)
+		      && fp_cfa_offset != -1)
 		    {
 		      vt_init_cfa_base ();
 		      hard_frame_pointer_adjustment = fp_cfa_offset;

  reply	other threads:[~2011-05-24 11:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-22 23:15 Eric Botcazou
2011-05-23 10:07 ` Jakub Jelinek
2011-05-23 10:25   ` Eric Botcazou
2011-05-23 12:04     ` Jakub Jelinek
2011-05-23 18:17     ` Jakub Jelinek
2011-05-24 12:21       ` Eric Botcazou [this message]
2011-05-24 12:26         ` Jakub Jelinek
2011-05-24 14:20           ` Eric Botcazou
2011-05-24 14:59             ` Jakub Jelinek
2011-05-24 23:44               ` Eric Botcazou
2011-05-29 16:14       ` Eric Botcazou
2011-05-30  9:55         ` Jakub Jelinek
2011-05-30 13:10           ` Eric Botcazou
2011-05-30 13:31             ` Jakub Jelinek
2011-05-30 17:10               ` Eric Botcazou
2011-05-30 10:07         ` Alexandre Oliva
2011-05-30 11:21           ` 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=201105241259.57887.ebotcazou@adacore.com \
    --to=ebotcazou@adacore.com \
    --cc=aoliva@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.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).