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.
Bernd.
