On 06/06/2014 01:44 AM, Richard Biener wrote:
On Fri, 6 Jun 2014, Richard Sandiford wrote:
[snip]
How about initialising the DECL_ALIGN to:
(TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_pfn
? 2 * BITS_PER_UNIT : BITS_PER_UNIT)
instead of function_boundary (NULL)? That way we might even be able to
rely on DECL_ALIGN in get_object_alignment_2.
Not sure about that, but initializing that way certainly looks
reasonable.
Btw, maybe we should call function_boundary to properly initialize
DECL_ALIGN earlier than output time, for example in
cgraph_finalize_function. There might be an IPA pass sorting
functions after their alignment to squeeze some more bits
by reducing possible padding.
Hrmmmm. I was looking again at handle_aligned_attribute in c-common.c,
which gives an error if you try to decrease the alignment from the
target-specific default given by FUNCTION_BOUNDARY. If we don't invoke
the new hook to set the default until after alignment attributes are
handled, we'll have to duplicate that logic.
More problematically, earlier in that file there is also code to handle
the __alignof__ operator. When the operand is a function type, it uses
FUNCTION_BOUNDARY; when the operand is a FUNCTION_DECL, it uses
DECL_ALIGN. So, if we defer setting the target-specific default after
the front end, we could potentially break all code that uses __alignof__
on functions.... :-(
Like I mentioned before, my guess was that the "right" place to set
DECL_ALIGN for functions is in layout_decl or some new equivalent for
functions. Postponing it to output time, or some random optimization
pass, seems likely to cause inconsistent behavior.
-Sandra
