This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using BIGGEST_ALIGNMENT to remove alignment constraints


On 26/11/13 16:12, Paulo Matos wrote:
> Hi,
> 
> I am slightly confused about the BIGGEST_ALIGNMENT docs which state: 
> "Biggest alignment that any data type can require on this machine, in
> bits. Note that this is not the biggest alignment that is supported,
> just the biggest alignment that, when violated, may cause a fault."
> 
> What kind of fault would this be? We currently have it set to 64,
> word_size. However, we really have no alignment restrictions being
> able to align data types to byte boundaries if necessary. Therefore,
> from this piece of code: unsigned int get_mode_alignment (enum
> machine_mode mode) { return MIN (BIGGEST_ALIGNMENT, MAX (1,
> mode_base_align[mode]*BITS_PER_UNIT)); }
> 
> I am tempted to set BIGGEST_ALIGNMENT to 8 so I can force GCC to just
> align the data at any byte boundary. Would this be a fair use of
> BIGGEST_ALIGNMENT? If not, then should BIGGEST_ALIGNMENT be equal to
> the largest supported mode on our machine? I am quite confused about
> what fault it could happen in BIGGEST_ALIGNMENT is violated,
> therefore for our machine I guess BIGGEST_ALIGNMENT can be as high as
> possible.
> 
> Paulo Matos
> 
> 

I don't know what sort of "fault" could be generated by larger
alignments, but the gcc manual gives a suggested usage of
__BIGGEST_ALIGNMENT__ in user code:

<http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html>

(Note - I am not sure whether BIGGEST_ALIGNMENT and
__BIGGEST_ALIGNMENT__ are in bits or bytes.)

The idea, I think, is that it should be the smallest size that makes
things like optimised memory copies as fast as possible.  Typically it
should match cache line sizes on the target.  Making it bigger than that
will mean that anyone following the advice in the manual would be
wasting space.


I can't see that BIGGEST_ALIGNMENT should ever be set to something
smaller than the alignment needed for the biggest types (double,
int64_t, or perhaps int128_t types).


For some uses, it's important to be able to allocate data with much
bigger alignments - in embedded systems I have had occasion to declare
data with very large alignments.

mvh.,

David


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]