On 06/05/2014 03:50 PM, Richard Sandiford wrote:
Sandra Loosemore <san...@codesourcery.com> writes:
On 06/05/2014 01:39 AM, Richard Biener wrote:
[snip]
Ok, we definitely need to preserve that (documented) behavior. I suppose
it also sets DECL_USER_ALIGN. -falign-functions is probably another
setter of DECL_ALIGN here.
If we add a target hook that may adjust function alignment then it
has to honor any user set alignment, then -falign-functions and
then it may only increase alignment over the default FUNCTION_BOUNDARY.
The point to adjust alignment with the hook may still be output time,
but as we figured it can't simply ignore DECL_ALIGN.
Hmmmm. The MIPS tweak we want here is to decrease the alignment for
certain functions, so I suppose this means we'd have to go about it
backwards by making FUNCTION_BOUNDARY 16 rather than 32 (at least for
-Os) and then later increasing it back to 32 for all non-microMIPS
functions.
Richard S., WDYT? Shall I hack up another patch that does it that way,
or do you think that's still the wrong way to go about it?
Well, it sounds like the idea is that FUNCTION_BOUNDARY should basically
be ignored as a DECL_ALIGN. The only cases where DECL_ALIGN should matter
are those where the user has set the alignment via command-line options
or attributes. If so, I'd rather just leave it as it is and make the
hook pick something smaller.
Just to be sure: I'd imagined this working by having varasm.c detect
when DECL_ALIGN needs to be honoured and having a hook to call when
DECL_ALIGN is irrelevant. The default version would then assert
that DECL_ALIGN is FUNCTION_BOUNDARY and would return that alignment.
The MIPS hook would override it for the special microMIPS case,
but would call into the default otherwise.
(Hmm, maybe for that level of detail I should just have written a patch.
Sorry about that...)
I'm willing to write/test a patch once you guys agree on the semantics
of the new hook and are happy with how it would be used to solve this
particular problem....
-Sandra
