On Tue, 3 Nov 2020, Bernd Edlinger wrote:
>
>
> On 11/3/20 10:34 AM, Richard Biener wrote:
> > On Mon, 2 Nov 2020, Bernd Edlinger wrote:
> >
> >> On 11/2/20 3:07 PM, Richard Biener wrote:
> >>> On Mon, 2 Nov 2020, Bernd Edlinger wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> this makes sure that stack allocated SSA_NAMEs are
> >>>> at least MODE_ALIGNED. Also increase the MEM_ALIGN
> >>>> for the corresponding rtl objects.
> >>>>
> >>>>
> >>>> Tested on x86_64-pc-linux-gnu and arm-none-eabi.
> >>>>
> >>>> OK for trunk?
> >>>
> >>>
> >>> @@ -1022,6 +1030,14 @@ expand_one_stack_var_at (tree decl, rtx base,
> >>> unsigned base_align,
> >>> }
> >>>
> >>> set_rtl (decl, x);
> >>> +
> >>> + if (TREE_CODE (decl) == SSA_NAME
> >>> + && GET_MODE (x) != BLKmode
> >>> + && MEM_ALIGN (x) < GET_MODE_ALIGNMENT (GET_MODE (x)))
> >>> + {
> >>> + gcc_checking_assert (GET_MODE_ALIGNMENT (GET_MODE (x)) <=
> >>> base_align);
> >>> + set_mem_align (x, GET_MODE_ALIGNMENT (GET_MODE (x)));
> >>> + }
> >>> }
> >>>
> >>>
> >>> I wonder whether we cannot "fix" set_rtl to not call
> >>> set_mem_attributes in this path, maybe directly call
> >>> set_mem_align there instead? That is, the preceeding
> >>> code for ! SSA_NAME already tries to adjust alignment
> >>> to honor that of the actual stack slot - IMHO the
> >>> non-SSA and SSA cases should be merged after this
> >>> patch, but maybe simply by calling set_mem_align
> >>> instead of doing the DECL_ALIGN frobbing and do
> >>> the alignment compute also for SSA_NAMEs?
> >>>
> >>> The other pieces look OK but the above is a bit ugly
> >>> at the moment.
> >>>
> >>
> >> Hmm, how about this?
> >
> > That would work for me. Guess removing the DECL_ALIGN frobbing
> > in the != SSA_NAME path didn't work out or you didn't try out
> > of caution?
> >
>
> I didn't try, since it felt simply more correct this way,
> and get_object_alignment would probably give a different
> answer since it uses DECL_ALIGN too.
OK, I see.
Richard.
