Hi, I'd like to ping for this patch: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00438.html
Thanks Bernd. On 3/10/19 10:42 AM, Bernd Edlinger wrote: > Hi, > > This patch is an update to the previous patch, which takes into account that > the middle-end is not supposed to use the unaligned DI value directly which > was passed in an unaligned stack slot due to the AAPCS parameter passing > rules. > > The patch works by changing use_register_for_decl to return false if the > incoming RTL is not sufficiently aligned on a STRICT_ALIGNMENT target, > as if the address of the parameter was taken (which is TREE_ADDRESSABLE). > So not taking the address of the parameter is a necessary condition > for the wrong-code in PR 89544. > > It works together with this check in assign_parm_adjust_stack_rtl: > /* If we can't trust the parm stack slot to be aligned enough for its > ultimate type, don't use that slot after entry. We'll make another > stack slot, if we need one. */ > if (stack_parm > && ((STRICT_ALIGNMENT > && GET_MODE_ALIGNMENT (data->nominal_mode) > MEM_ALIGN > (stack_parm)) > ... > stack_param = NULL > > This makes assign_parms use assign_parm_setup_stack instead of > assign_parm_setup_reg, and the latter does assign a suitably aligned > stack slot, because stack_param == NULL by now, and uses emit_block_move > which avoids the issue with the back-end. > > Additionally, to prevent unnecessary performance regressions, > assign_parm_find_stack_rtl is enhanced to make use of a possible larger > alignment if the parameter was passed in an aligned stack slot without > the ABI requiring it. > > > Bootstrapped and reg-tested with all languages on arm-linux-gnueabihf. > Is it OK for trunk? > > > Thanks > Bernd. >
