On Thu, Jan 10, 2019 at 2:32 PM Jakub Jelinek <ja...@redhat.com> wrote: > > Hi! > > On Thu, Jan 10, 2019 at 04:36:35PM +0100, Eric Botcazou wrote: > > > If there are other spots that need this, wondering about: > > > else > > > copy = assign_temp (type, 1, 0); > > > in calls.c, either it can be done by using the variable-sized object > > > case in the then block, or could be done using assign_stack_local + > > > this short realignment too. > > > > The latter I'd say. > > Will handle that tomorrow. > > But, there is another thing, while assign_stack_local_1 lowers > alignment_in_bits to MAX_SUPPORTED_STACK_ALIGNMENT if it is higher than that > and records that in the MEM it creates, the caller, > assign_stack_temp_for_type will happily count with higher alignments and > on the MEMs it creates will happily set MEM_ALIGN to the higher value. > I think we shouldn't lie here, something in the optimizers could try to take > advantage of the higher MEM_ALIGN. > > Bootstrapped/regtested on x86_64-linux and i686-linux, but that doesn't mean > much, because MAX_SUPPORTED_STACK_ALIGNMENT there is 1 << 28. Guess more > useful would be to test it on mingw where BIGGEST_ALIGNMENT is often higher > than MAX_SUPPORTED_STACK_ALIGNMENT.
FWIW, MAX_SUPPORTED_STACK_ALIGNMENT is an arbitrary large value for Linux/x86 since we track and align stack as needed. -- H.J.
