From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id 17E45384F6DC for ; Fri, 18 Nov 2022 05:02:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 17E45384F6DC Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pl1-x62e.google.com with SMTP id w23so3574478ply.12 for ; Thu, 17 Nov 2022 21:02:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=o6zqmArHu7HSlaqcSQ78qVWPxcFxKrSBM5CA3t0HS0c=; b=VS+kxrzdcVUgxHEczdTD2MQTWTfQKp8ko4APke7QvBNo6ohAyxpmZFxXiPSuS/kDmH VZMcuiKraWvfvsKcrj1LuIzm8UEl44Q51RPPWrF9p141qu+9p7uFNZB25yFKV6NCl9B3 lBEZkCenPwtTdF2dhNf50ZS/5vVTptBadYd0bITpWhiYNnz66TKS6WoJRX7H26VpXOEJ gHXfoo1FGv7jbAdR+3Zq4guaivc2e6Tted9YPwh4W/XmEDlr1O3q8SSiR1mqL0N1Vqi5 QfHUECPWrNbLHerDDXshE1/sCXiceo+ONpOcjpEIIqzrhFpeHwollOkKBHM5TIpq/MAH UWZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=o6zqmArHu7HSlaqcSQ78qVWPxcFxKrSBM5CA3t0HS0c=; b=5sp2h8UH/R/l3LTs4fojFD4WbCSsuK/MvkgZ8sKETyI30/cB42udPCAl+6o8DfB0Pu /ncJ1jbY8twDntC6Qu2gfdkstLL48BA+yaM2cmkLIc7ixDcy+W2jfKDPG1Zr4PKRLjVi oYSIpZJCwnH1SA400mk54h2hTUC1i5oky/4/fNhcgD1oE2lGCe02DZpELa1aLUmTBz4l IAa6kjwqAR9hSJ5lN/XN149CpgDcyHlBNlhkB+OxgADmNmssrQiPrn2Ke2LfM8+FXzgL JWN/5iSqSjNARd/VYE8E83OcC6Xh2nohgk0MrzYri7wLFrWVVRBtgEAobLubMtS6y1dy u91A== X-Gm-Message-State: ANoB5pkYmkE8PB7CqOlfkrbCL96rhxlPoMvnU6SM4QKNRpjRQPpAAKjI w/DHwdYWKTJFA33ykAIWAd6hxKLyGrTDKQ== X-Google-Smtp-Source: AA0mqf5IuORS0Dk1Z+0v/y+GpHOZKfLNT9D/4JHnHx1Cy2i/f8UkTgDmHtiiomvJrWJvp/4RrV5r+w== X-Received: by 2002:a17:90a:e007:b0:213:193a:dc84 with SMTP id u7-20020a17090ae00700b00213193adc84mr12453111pjy.2.1668747763670; Thu, 17 Nov 2022 21:02:43 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id u13-20020a170903124d00b00186ad73e2d5sm2374966plh.208.2022.11.17.21.02.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Nov 2022 21:02:43 -0800 (PST) Date: Thu, 17 Nov 2022 21:02:43 -0800 (PST) X-Google-Original-Date: Thu, 17 Nov 2022 21:02:38 PST (-0800) Subject: Re: [PATCH] Ver.2: Add compile option "-msmall-data-limit=0" to avoid using .srodata section for riscv. In-Reply-To: CC: gcc-patches@gcc.gnu.org, chenyixuan@iscas.ac.cn, Kito Cheng , Andrew Waterman , jiawei@iscas.ac.cn From: Palmer Dabbelt To: oriachiuan@gmail.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.4 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 于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 >> >> >> >> * 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... >>