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]
Other format: [Raw text]

Re: [RFC,PATCH] Introduce -msdata=explicit for powerpc


Hi!

On Tue, Aug 07, 2018 at 02:18:59AM -0300, Alexandre Oliva wrote:
> This option allows users to manually select what goes in the limited
> small data range, and still get smaller and faster small data access
> sequences for the selected data.

> We've considered adding a new attribute, say "sdata", to let the
> compiler pick the sdata/sbss section name itself, but that's not
> strictly necessary since attribute section already does what we need.
> I'm not sure how the semantics of conflicting attributes should be
> implemented, but if others think it's a good idea, I could give it a
> shot.  Like, if attribute((sdata, section("data"))) is given, should the
> variable be placed in .data but be accessed using sdata addressing
> modes?  Should we reject that with an error?  Should we warn and ignore
> one of the attributes?  Something else?

> 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.  What do the ABIs say?

> 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.

You can use different -msdata options per object file, maybe tune -G a
bit, and change that section attribute (or the target attribute) where
you want to (or does that not work?)

The approach looks like it should work, but it does not seem all that
convenient to me.  Well I'm sure you try it out on a reasonably sized
project, and you'll find out if it is handy or not :-)


Segher


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