On Tue, 9 Aug 2011, Hans-Peter Nilsson wrote:
> 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.
Committed.
I think the max-align argument to get_{pointer,object}_alignment
doesn't make much sense. I'll cook up a patch to remove them.
Richard.
