Matthew Dillon wrote:
>
> :> > Anyhow, I'll repeat it here - stack alignment does *not* break
> :> > link-compatibility. It does not change calling conventions, it just
> :> > adds padding after the args to ensure that local variables can be
> :> > predictably aligned.
> :
> :> So, how does aligning stackframes affect the inherently static property
> :> of code size then?
> :
> :Instructions are inserted to perform that alignment (add padding).
> :When the alignment is 2 (i.e. on 4-byte boundaries), no padding is
> :required in typical cases.
>
> I can't think of a single case where the stack isn't inherently
> 4-byte aligned already, whether you use the option or not.
It's more a case of overriding the new behaviour of gcc to align the
stack on 16-byte boundaries by default (for performance reasons for the
PIII SIMD instructions, IIRC)
> To whomever added the option: Did you actually test to see that
> this option resulted in an improvement? If not, I recommend removing
> it. It sounds like unnecessary extra junk to me.
For the bootcode the option is necessary. It does remove a lot of "subl
$..,%esp" instructions that bloated the code, which in turn prevented
boot2 to build. It's not necessary for kernel/module builds. But the
option does prevent a lot of unnecessary alignment instructions in the
code...
Maybe -mpreferred-stack-boundary=2 should be the default so that we
don't need the option in the general case. Overriding this in certain
cases, can be considered an optimisation...
--
Marcel Moolenaar mailto:[EMAIL PROTECTED]
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD project mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
