Re: [rfc] allow -G to take a range

[Michael Meissner <gcc-pat at the-meissners dot org>]

On Tue, May 27, 2003 at 08:21:52PM -0400, DJ Delorie wrote:
> 
> > I don't know if you want to generalize it further to add alignment
> > too.
> 
> Misunderstanding.  The next thing I'm looking at is grouping .sdata
> items by alignment, so that they can be packed more efficiently.  In
> other words, instead of char-fill-int-char-fill-int, it would go
> char-char-fill-int-int.
> 
> It looks like doing this on a per-module basis (i.e. no linker
> changes) isn't going to pan out, since gcc emits decls as it
> encounters them instead of all at once.

Also, you don't know until link time which globals have been initialized, which
are common decls, and which aren't referenced and not linked in with the
appropriate switches.  Statics are easier.  Once we switch over to whole file
at a time (tree-ssa?) the compiler will know which things to emit.

By the way, you can already do this with TARGET_ASM_SELECT_SECTION,
TARGET_ENCODE_SECTION_INFO, and friends.

> > I could see that you might not want char aligned items there.
> > Another thought (that may be done by now, I haven't looked at the
> > code recently) is to have the linker put things that don't have the
> > appropriate relocation records against them don't get put into
> > .sdata/.sbss.
> 
> That would mean that each object would have to be in its own section
> in the object, so that the linker can arrange them and/or exclude them
> as needed.  The grouping idea I had was to create sections like
> .sdata.0, .sdata.1, .sdata.2, etc, corresponding to log2 alignment.
> What you'd need is more like the linkonce support.

I was thinking more for globals, where they already are their own section.  But
it is simple enough to create such sections for statics too.

> > The machine I'm starting to work on shifts its signed offset by the
> > data size, which means I'm going to want to sort 1 byte aligned
> > items in the middle of the GP area, then the 2 byte aligned items,
> > then the 4, etc.
> 
> Sounds like my grouping idea would help, modulo the .sbss/.sdata thing
> (i.e.  you could easily put less aligned things near the sdata/sbss
> border, but arranging to have them near the 32k mark is harder).

Yep.  The first pass will be having .sdata1, .sdata2, .sdata4, etc. and the
linker script just links .sdata1 first, then .sdata2, etc.  That is easy.
After that I need to either have the linker distribute things, or have parallel
.sdata sections (ie, .sdatan1, .sdatan2, etc.) that are for negative offsets,
and just have the user assign the variables there directly.

> > In some senses, it would be better to drop this all on the app, and
> > rather than have the compiler automatically choose, to only put
> > things that the user specifically requested into the small data
> > area.
> 
> Yup, something else I'm thinking of, both inclusion and exclusion
> overrides.

The rs6000/powerpc and V850 ports already allow the user to use:

	__atribute__((__section__("str")))

to hardwire the sections.  IIRC, the V850 had 3 small data areas.

-- 
Michael Meissner
email: gnu@the-meissners.org
http://www.the-meissners.org