Re: The macro STACK_BOUNDARY may overflow

[Jeff Law <jeffreyalaw@gmail.com>]

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