This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: allow for small DECL_OFFSET_ALIGN.
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Subject: Re: allow for small DECL_OFFSET_ALIGN.
- From: Geoff Keating <geoffk at cygnus dot com>
- Date: 18 May 2000 12:10:10 -0700
- CC: gcc-patches at gcc dot gnu dot org
- References: <10005180214.AA05238@vlsi1.ultra.nyu.edu>
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>