On Aug 7, 2018, Segher Boessenkool <seg...@kernel.crashing.org> wrote:
> Hi!
Hi!
> 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,
SDATA2_SECTION_ASM_OP);
but sdata2_section seems to be unused, and I don't see anything that
selects r2 over SMALL_DATA_REG.
>> 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.
Thanks,
--
Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain Engineer Free Software Evangelist
