From: Palmer Dabbelt <palmer@dabbelt.com>
To: oriachiuan@gmail.com
Cc: gcc-patches@gcc.gnu.org, chenyixuan@iscas.ac.cn,
Kito Cheng <kito.cheng@gmail.com>,
Andrew Waterman <andrew@sifive.com>,
jiawei@iscas.ac.cn
Subject: Re: [PATCH] Ver.2: Add compile option "-msmall-data-limit=0" to avoid using .srodata section for riscv.
Date: Thu, 17 Nov 2022 21:02:43 -0800 (PST) [thread overview]
Message-ID: <mhng-1d1f2c07-5ca9-4ce0-88e6-1f01f24d1535@palmer-ri-x1c9a> (raw)
In-Reply-To: <CABLCG8237LPqdrUWkzPQ3zMAfd0RJ_bD+xz7uppDMnyXuMW7BA@mail.gmail.com>
On Thu, 17 Nov 2022 19:30:23 PST (-0800), oriachiuan@gmail.com wrote:
> Got it, I used to regard this test case as targeting at test if the const
> data would use the ".rodata" section.
Sorry, I'm not quite sure what you're trying to say here. Here's a dump
of how I see things:
In some targets (RISC-V and MIPS) there's multiple copies of the
data/rodata sections, with the small data/rodata ending up in the small
sections (`.sdata` and `.srodata`). I've never actually been 100% on
that being allowed by any spec, but MIPS did it long before RISC-V so I
figure software is expected to tolerate the oddness.
In RISC-V we use it to try and place as many symbols as possible close
to GP, so we're more likely to relax to GP-relative addressing
sequences. IIRC that's pretty much the same as MIPS, though they have
slightly different addressing requirements.
For targets that function this way `.srodata` and `.rodata` are
functionally equivalent (assuming you're not playing any GP tricks to
relocate, but those are way out of what's supported). So unless the
test is trying to dig into performance issues differences between these
sections, it should just allow code to target either.
>
> Palmer Dabbelt <palmer@dabbelt.com> 于2022年11月18日周五 07:59写道:
>
>> On Thu, 17 Nov 2022 13:50:00 PST (-0800), gcc-patches@gcc.gnu.org wrote:
>> >
>> > On 11/17/22 02:53, Yixuan Chen wrote:
>> >> 2022-11-17 Yixuan Chen <chenyixuan@iscas.ac.cn>
>> >>
>> >> * gcc/testsuite/gcc.dg/pr25521.c: Add compile option
>> "-msmall-data-limit=0" to avoid using .srodata section for riscv.
>> >> ---
>> >> gcc/testsuite/gcc.dg/pr25521.c | 3 ++-
>> >> 1 file changed, 2 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/gcc/testsuite/gcc.dg/pr25521.c
>> b/gcc/testsuite/gcc.dg/pr25521.c
>> >> index 74fe2ae6626..628ddf1a761 100644
>> >> --- a/gcc/testsuite/gcc.dg/pr25521.c
>> >> +++ b/gcc/testsuite/gcc.dg/pr25521.c
>> >> @@ -2,7 +2,8 @@
>> >> sections.
>> >>
>> >> { dg-require-effective-target elf }
>> >> - { dg-do compile } */
>> >> + { dg-do compile }
>> >> + { dg-options "-msmall-data-limit=0" { target { riscv*-*-* } } } */
>> >>
>> >> const volatile int foo = 30;
>> >>
>> >
>> > Wouldn't this be better? It avoids a target specific conditional by
>> > instead extending what we look for to cover [s]rodata sections.
>> >
>> >
>> > Thoughts?
>> >
>> > Jeff
>> > diff --git a/gcc/testsuite/gcc.dg/pr25521.c
>> b/gcc/testsuite/gcc.dg/pr25521.c
>> > index 74fe2ae6626..63363a03b9f 100644
>> > --- a/gcc/testsuite/gcc.dg/pr25521.c
>> > +++ b/gcc/testsuite/gcc.dg/pr25521.c
>> > @@ -7,4 +7,4 @@
>> > const volatile int foo = 30;
>> >
>> >
>> > -/* { dg-final { scan-assembler "\\.rodata" } } */
>> > +/* { dg-final { scan-assembler "\\.s\?rodata" } } */
>>
>> That's how I usually do it for these tests, there's some other targets
>> with sdata too so it fixes the test for everyone. IIRC I said something
>> like that in the v1, but sorry if I'm just getting it confused with some
>> other patch.
>>
>> There's a few of these that need to get chased down for every release,
>> maybe we should add some sort of DG hepler? Not sure that'd keep folks
>> from matching on .data, though...
>>
next prev parent reply other threads:[~2022-11-18 5:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 9:53 Yixuan Chen
2022-11-17 21:50 ` Jeff Law
2022-11-17 23:59 ` Palmer Dabbelt
2022-11-18 3:30 ` Oria Chiuan
2022-11-18 5:02 ` Palmer Dabbelt [this message]
2022-11-18 5:21 ` Oria Chiuan
2022-11-18 5:52 ` 陈逸轩
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mhng-1d1f2c07-5ca9-4ce0-88e6-1f01f24d1535@palmer-ri-x1c9a \
--to=palmer@dabbelt.com \
--cc=andrew@sifive.com \
--cc=chenyixuan@iscas.ac.cn \
--cc=gcc-patches@gcc.gnu.org \
--cc=jiawei@iscas.ac.cn \
--cc=kito.cheng@gmail.com \
--cc=oriachiuan@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).