On Tue, 9 Aug 2011, Richard Guenther wrote:
>
> This fixes PR49937 - callers of get_{pointer,object}_alignment
> probably should not use BIGGEST_ALIGNMENT to limit what these
> functions return (why do they do that? Maybe because formerly
> the routines returned TYPE_ALIGN? But why wasn't that bound by
> BIGGEST_ALIGNMENT?) - some targets define that as 8 (such as cris or avr).
ISTM such limiting is only valid when constructing non-function
pointers to unknown data and the goal is to error on the safe
side regarding generally unknown data placement and alignment.
(If it's known to be on stack or in constant or static storage,
there are other macros.)
BIGGEST_ALIGNMENT is not what its name says. As can be seen in
the docs; it's rather something like
BIGGEST_MINIMAL_HARDWARE_ENFORCED_ALIGNMENT_FOR_DATA_ACCESS.
Point being, it's likely there's a greater alignment that's
preferable for e.g. performance reasons when generating objects
and pointers to them.
BIGGEST_ALIGNMENT cannot be used for checking alignment of
function pointers (to see e.g. how many low bits can be
scavenged for hacks). Raising BIGGEST_ALIGNMENT to include
FUNCTION_BOUNDARY would be just wrong, as that's not data being
accessed.
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
And regtest cross to cris-elf passes at r177605.
brgds, H-P
