This is the mail archive of the 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: [RFC,PATCH] Introduce -msdata=explicit for powerpc

On Wed, Aug 08, 2018 at 12:38:54AM -0300, Alexandre Oliva wrote:
> On Aug  7, 2018, Segher Boessenkool <> wrote:
> > On Tue, Aug 07, 2018 at 02:18:59AM -0300, Alexandre Oliva wrote:
> >> I saw comments, docs and init code that suggested the possibility of
> >> using r2/.sdata2 for small data, but I couldn't get code to be generated
> >> for such access, even with very old toolchains.  I'm not sure I'm just
> >> missing how this magic comes about, or whether it hasn't been available
> >> for a very long time but nobody removed the comments/docs.  Assuming I'm
> >> missing something, I put in the possibility of using r2 in the test in
> >> the patch, but I'm sure I have not exercised it to make sure I got it
> >> right.  Help?
> > attribute(section("sdata2")))  works, perhaps.  Nothing is put there
> > implicitly afais.
> Yeah, that's the point.  Docs say:
> @item -msdata=eabi
> @opindex msdata=eabi
> On System V.4 and embedded PowerPC systems, put small initialized
> @code{const} global and static data in the @code{.sdata2} section, which
> is pointed to by register @code{r2}.  Put small initialized
> non-@code{const} global and static data in the @code{.sdata} section,
> which is pointed to by register @code{r13}.  [...]
> and rs6000.c contains:
> rs6000_elf_asm_init_sections (void)
> {
> [...]
>   sdata2_section
>     = get_unnamed_section (SECTION_WRITE, output_section_asm_op,
> but sdata2_section seems to be unused, and I don't see anything that
> selects r2 over SMALL_DATA_REG.

So, you need to build a powerpc-eabi- toolchain, and use -msdata=eabi.
Then you get sdata2 used (via srodata in generic code), and it is accessed
via GPR2 (via the sda21 reloc and linker magic).  It is hard to trace down :-)

> >> I have not YET given this much testing.  I'm posting it so as to give
> >> ppc maintainers an opportunity to comment on the proposed approach, in
> >> hopes of getting buy-in for the idea, if not necessarily for the patch,
> >> but I welcome alternate suggestions to enable users to choose what goes
> >> in faster sdata when there's too much data for size-based assignment to
> >> place interesting variables in sdata without overflowing its range.
> > There is 64kB of sdata, and the maximum size of an object to be put there
> > is 8 bytes by default.  That will require an awful lot of manual markup.
> In this case, it's machine-generated code we're talking about.  IIUC one
> large-ish data set is performance critical, and another data set that
> would take them both over the edge isn't, though they're both used
> together in the same translation units.
> I suppose defining a fastint C macro / Fast_Integer Ada subtype in some
> C header file or Ada package could make it a lot more appealing and easy
> to use ;-)
> > Well I'm sure you try it out on a reasonably sized
> > project, and you'll find out if it is handy or not :-)
> I wanted to run this design through port maintainers to check for
> objections before offering it to the interested customer.  If you tell
> me there's no fundamental objection, I will have it run through the
> customer to confirm it will indeed meet their needs.

It looks fine, not intrusive, and your use case is reasonable as well.
Shouldn't be a problem.


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