public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Paul Iannetta <piannetta@kalrayinc.com>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: gcc@gcc.gnu.org
Subject: Re: The macro STACK_BOUNDARY may overflow
Date: Fri, 12 Jan 2024 11:15:11 +0100	[thread overview]
Message-ID: <20240112101511.ju3hpxxxv2bygzeo@kalrayinc.com> (raw)
In-Reply-To: <d6ef9207-7892-023f-7d11-bb84dff6cdca@gmail.com>

On Sat, Mar 25, 2023 at 10:28:02AM -0600, Jeff Law via Gcc wrote:
> On 3/24/23 07:48, Paul Iannetta via Gcc wrote:
> > Hi,
> > 
> > Currently, the macro STACK_BOUNDARY is defined as
> > 
> >    Macro: STACK_BOUNDARY
> >       Define this macro to the minimum alignment enforced by hardware for
> >       the stack pointer on this machine.  The definition is a C
> >       expression for the desired alignment (measured in bits).  This
> >       value is used as a default if 'PREFERRED_STACK_BOUNDARY' is not
> >       defined.  On most machines, this should be the same as
> >       'PARM_BOUNDARY'.
> > 
> > with no mentions about its type and bounds.  However, at some point, the value
> > of this macro gets assigned to the field "regno_pointer_align" of "struct
> > emit_status" which points to an "unsigned char", hence if STACK_BOUNDARY gets
> > bigger than 255, it will overflow...  Thankfully, the backend which defines the
> > highest value is microblaze with 128 < 255.
> > 
> > The assignment happens in "emit-rtl.c" through the REGNO_POINTER_ALIGN macro:
> > 
> > in function.h:
> >    #define REGNO_POINTER_ALIGN(REGNO) (crtl->emit.regno_pointer_align[REGNO])
> > in emit-rtl.cc:
> >    REGNO_POINTER_ALIGN (STACK_POINTER_REGNUM) = STACK_BOUNDARY;
> >    [...]
> >    REGNO_POINTER_ALIGN (VIRTUAL_OUTGOING_ARGS_REGNUM) = STACK_BOUNDARY;
> > 
> > Would it be possible to, either add an explicit bound to STACK_BOUNDARY in the
> > manual, and/or use an "unsigned int *" rather than and "unsigned char *" for
> > the field "regno_pointer_align".
> Feel free to send a suitable patch to gcc-patches.  THe alignment data isn't
> held in the RTX structures, so it's not critical that it be kept as small as
> possible.  We don't want to waste space, so an unsigned short might be
> better.  A char was good for 30 years, so we don't need to go crazy here.
> 
> The alternative would be to change the representation to store the log2 of
> the alignment.  That would be a much larger change and would trade off
> runtime for memory consumption.  I would have suggested this approach if the
> data were in the RTX structures amd space at a premium.
> 
> While I do see a trend in processor design to reduce/remove the misalignment
> penalties (thus eliminating the driver for increasing data alignment),
> that's been primarily in high end designs.
> 
> jeff

Hi,

Here is a patch that changes the type of the variable holding the
alignment to unsigned short for the reasons outlined above.  Should I
also mention the new upper bound for STACK_BOUNDARY in the
documentation or keep it silent?

Thanks,
Paul

---->8-------------------------------------------------------8<----
From: Paul Iannetta <piannetta@kalrayinc.com>
Date: Fri, 12 Jan 2024 10:18:34 +0100
Subject: [PATCH] make regno_pointer_align a unsigned short*

This changes allows to align values greater than 128 to be used for
alignment.

	* emit-rtl.cc (emit_status::ensure_regno_capacity): Change
	  unsigned char* to unsigned short*
	(init_emit): Likewise.
	* function.h (struct GTY): Likewise.
---
 gcc/emit-rtl.cc | 6 +++---
 gcc/function.h  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/emit-rtl.cc b/gcc/emit-rtl.cc
index 1856fa4884f..f0f0ad193b5 100644
--- a/gcc/emit-rtl.cc
+++ b/gcc/emit-rtl.cc
@@ -1231,9 +1231,9 @@ emit_status::ensure_regno_capacity ()
   while (reg_rtx_no >= new_size)
     new_size *= 2;
 
-  char *tmp = XRESIZEVEC (char, regno_pointer_align, new_size);
+  short *tmp = XRESIZEVEC (short, regno_pointer_align, new_size);
   memset (tmp + old_size, 0, new_size - old_size);
-  regno_pointer_align = (unsigned char *) tmp;
+  regno_pointer_align = (unsigned short *) tmp;
 
   rtx *new1 = GGC_RESIZEVEC (rtx, regno_reg_rtx, new_size);
   memset (new1 + old_size, 0, (new_size - old_size) * sizeof (rtx));
@@ -5972,7 +5972,7 @@ init_emit (void)
   crtl->emit.regno_pointer_align_length = LAST_VIRTUAL_REGISTER + 101;
 
   crtl->emit.regno_pointer_align
-    = XCNEWVEC (unsigned char, crtl->emit.regno_pointer_align_length);
+    = XCNEWVEC (unsigned short, crtl->emit.regno_pointer_align_length);
 
   regno_reg_rtx
     = ggc_cleared_vec_alloc<rtx> (crtl->emit.regno_pointer_align_length);
diff --git a/gcc/function.h b/gcc/function.h
index 2d775b877fc..c4a20060844 100644
--- a/gcc/function.h
+++ b/gcc/function.h
@@ -72,7 +72,7 @@ struct GTY(()) emit_status {
   /* Indexed by pseudo register number, if nonzero gives the known alignment
      for that pseudo (if REG_POINTER is set in x_regno_reg_rtx).
      Allocated in parallel with x_regno_reg_rtx.  */
-  unsigned char * GTY((skip)) regno_pointer_align;
+  unsigned short * GTY((skip)) regno_pointer_align;
 };






      reply	other threads:[~2024-01-12 10:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-24 13:48 Paul Iannetta
2023-03-25 16:28 ` Jeff Law
2024-01-12 10:15   ` Paul Iannetta [this message]

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=20240112101511.ju3hpxxxv2bygzeo@kalrayinc.com \
    --to=piannetta@kalrayinc.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jeffreyalaw@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).