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...) Richard
