not too big an alignment

Richard Biener richard.guenther@gmail.com
Wed Nov 13 11:09:00 GMT 2013


On Tue, Nov 12, 2013 at 10:53 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Nov 12, 2013 at 01:42:00PM -0800, Mike Stump wrote:
>> On Nov 12, 2013, at 1:16 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> > On Tue, Nov 12, 2013 at 01:11:04PM -0800, Mike Stump wrote:
>> >> Alignments are stored in a byte, large alignments don't actually work nicely.  This caps the alignment to 128, as most ports would define BIGGEST_ALIGNMENT to be smaller than this.  The competing change would to be to make it a short, but, I'd be happy to punt that until such time as someone actually needs that.
>> >>
>> >> Ports break down this way currently:
>> >>
>> >>  12 #define BIGGEST_ALIGNMENT 64
>> >>  10 #define BIGGEST_ALIGNMENT 32
>> >>   6 #define BIGGEST_ALIGNMENT 128
>> >>   3 #define BIGGEST_ALIGNMENT 8
>> >>   8 #define BIGGEST_ALIGNMENT 16
>> >
>> > You are missing i386 that has BIGGEST_ALIGNMENT 512 (or less, depending on
>> > compiler options).  So this doesn't look right.
>>
>> And yet alignments for modes with sizes like 256 won't work and i386 has no mode with alignment bigger than 128 in this table.
>
> Well, BIGGEST_ALIGNMENT is in bits, while mode_base_align seems to be in bytes it
> seems:
>
> unsigned int
> get_mode_alignment (enum machine_mode mode)
> {
>   return MIN (BIGGEST_ALIGNMENT, MAX (1, mode_base_align[mode]*BITS_PER_UNIT));
> }
>
> So, supposedly it works up to 1024 bit alignment right now.

Either storing log2 (alignment) in mode_base_align or increasing its
size is possible if required.  IIRC we store alignment log2 elsewhere.

Richard.

>         Jakub



More information about the Gcc-patches mailing list