------- Comment #33 from hjl dot tools at gmail dot com 2009-03-03 14:48
-------
(In reply to comment #32)
> I don't see the reason for && optimize_function_for_size_p (cfun), care to
> back
> up with benchmarks that forcing dynamic realignment for long long variables
> with -mpreferred-stack-boundary=2 improves performance rather than slows
> things
> down (because of the dynamic realignment)?
>
> Also, I fail to see why 2 hunks in ix86_local_alignment are needed instead of
> just one. The second hunk won't catch !type case, where we have just mode
> (but
> no need to test type && there, type is always non-NULL).
>
> I think:
> --- i386.c2009-03-02 09:45:43.000000000 +0100
> +++ i386.c2009-03-03 11:35:21.000000000 +0100
> @@ -19351,6 +19351,14 @@ unsigned int
> ix86_local_alignment (tree type, enum machine_mode mode,
> unsigned int align)
> {
> + /* Don't do dynamic stack realignment for long long objects with
> + -mpreferred-stack-boundary=2. */
> + if (!TARGET_64BIT
> + && align == 64
> + && ix86_preferred_stack_boundary < 64
> + && (mode == DImode || (type && TYPE_MODE (type) == DImode)))
> + align = 32;
> +
> /* If TYPE is NULL, we are allocating a stack slot for caller-save
> register in MODE. We will return the largest alignment of XF
> and DF. */
>
> should be sufficient.
>
I am not against this patch. I just want to mention that
---
void foo (unsigned long long *);
void
bar (void)
{
unsigned long long l __attribute__ ((aligned(8)));
foo (&l);
}
---
won't work with -m32 -Os -mpreferred-stack-boundary=2 when
this patch is applied.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
