This is the mail archive of the gcc-patches@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]

Re: allow for small DECL_OFFSET_ALIGN.


kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     I took a slightly different approach, because all uses of
>     DECL_OFFSET_ALIGN are bounded by BIGGEST_ALIGNMENT, so I just simply
>     set DECL_OFFSET_ALIGN to BIGGEST_ALIGNMENT if it is larger than that.
> 
> My intent was indeed to do that.  If I didn't someplace, that was a bug.

stor-layout.c:422:  rli->offset_align = MAX (rli->record_align, BIGGEST_ALIGNMENT);

It might help to add in 'if (rli->offset_align > BIGGEST_ALIGNMENT) abort();'
in stor-layout.c just before the line that reads:

  DECL_OFFSET_ALIGN (field) = rli->offset_align;

then you would know when this goes wrong.

>     That posting also worries about the new size of DECL_ALIGN, because it
>     is 24 bit and in bits, so we don't support alignments up to .5GB any
>     longer, only up to 2MB. I don't know if some projects use larger
>     alignment for some objects, but if they do, they loose. 
> 
> I'm assuming that such large alignment don't make much sense.

For objects, they do, because it's perfectly valid to ask that some
particular object be page-aligned (on ppc, this means aligned to as
much as 32k bytes), or perhaps even segment-aligned (and segments are
256M).  I don't know about this for _fields_.

>     So perhaps if DECL_ALIGN would be stored as log2 of the real
>     alignment, we could overcome this as well.
> 
> There is an advantage of doing that anyway, of course.

Not least of which is that on ppc, BIGGEST_ALIGNMENT could legitimately
be 256, because there is an insn that clears a cache line.
-- 
- Geoffrey Keating <geoffk@cygnus.com>

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