From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) by sourceware.org (Postfix) with ESMTPS id 203733858C2C for ; Fri, 26 May 2023 18:50:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 203733858C2C Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com Received: by mail-qt1-x82b.google.com with SMTP id d75a77b69052e-3f51ea3a062so24841cf.1 for ; Fri, 26 May 2023 11:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1685127037; x=1687719037; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=NCbnFwpu/HH5tzHQ9riaaU4nubA58bJNddM9JyBto8g=; b=xtizjhf6zINeVerwFjvZcZbZnxrwCifaYHmf/c0uKS7sEWnbybvi7nubo18wJr1lZU t3nqXD205NSYCNBC8o/O9N1BLDEBIfQTWoyC9uds4xYc1nY6vi2iQp4jT0KcuXVMekmf VNPiU9yYmYE67m+ijFiekCSewPCl9yK16BHQrYnCfwZ9Yb9R7ZLxvfgmYAZJTVLP2bmP /88r7SeUsDZgo0ufjIe5SMFrH1mD5pdnSSeTYeTwiCNF2xf0LmAlQmtHzCxc3vAW5Bjm dvGiyCk2AuWDNAD8HMeJGC9wpG572qn1QKMMzvmRGUCCgoJJycb89P2MjhUivpSAJgvm CzzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685127037; x=1687719037; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NCbnFwpu/HH5tzHQ9riaaU4nubA58bJNddM9JyBto8g=; b=DukRgea/qwEA/Y3UklwLXBzxJpxzeBu+tCsrSPTJWOGbqrXr2l6LRkjPcjUsEfH7/K qHO2SpXL4UD7TiF2onocQRyRThiU7Ewtf26MyS7ujpPgTGtKkj3aPJackcAkFMTAJTW6 o4wD9Zee5mcnq0apKAzo35thNH0e6N2AZ9EdIIZhyNeevg87nCBxOCzNLINbFEOaqfJV kiMIUFZ/zjIbcOYArROfnafQamRObfs7qB8IWJkKCK/0fL2XPFA4Eal/CY//JpXGVo/m hxDhq8nXEDyw30pMNc+DCEyt0idVnEb7Nw1XzbRaMXKP+LKUiyMyLI0y3LOZDI694zYu qGJA== X-Gm-Message-State: AC+VfDz3vyoPQ4+8N/bKdgRY6EzL3FMtGJhxU7sHDnfdgJRWlGEsexYO z8PDDSlFGdCkDvyaRu4X4XP4SZ5j3bqMjf3A3wkjGg== X-Google-Smtp-Source: ACHHUZ705Ll+/T2ArRRplbZrNu1kTu4mTSGmsfEj8/Ro9CkqEoXEEc3ahgtbUZuFRL7ZcXIhZ7gorSikVhip9ZCQnug= X-Received: by 2002:a05:622a:182a:b0:3ee:d8fe:6f5c with SMTP id t42-20020a05622a182a00b003eed8fe6f5cmr17244qtc.1.1685127037489; Fri, 26 May 2023 11:50:37 -0700 (PDT) MIME-Version: 1.0 References: <20230525151632.3567825-1-maskray@google.com> <7a627f23-a603-a6cf-90bd-0cd430e7232f@suse.com> <20230525161157.yixwnjqfed56zedw@google.com> <9527a604-788a-a17f-2102-8466e3f7a209@suse.com> In-Reply-To: <9527a604-788a-a17f-2102-8466e3f7a209@suse.com> From: Fangrui Song Date: Fri, 26 May 2023 11:50:26 -0700 Message-ID: Subject: Re: [PATCH v2] i386: Allow -mlarge-data-threshold with -mcmodel=large To: Jan Beulich Cc: gcc-patches@gcc.gnu.org, Florian Weimer , "H.J. Lu" , Jan Hubicka , Michael Matz , Uros Bizjak Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 Fri, May 26, 2023 at 12:11=E2=80=AFAM Jan Beulich wr= ote: > > On 25.05.2023 18:11, Fangrui Song wrote: > > On 2023-05-25, Jan Beulich wrote: > >> On 25.05.2023 17:16, Fangrui Song wrote: > >>> --- a/gcc/doc/invoke.texi > >>> +++ b/gcc/doc/invoke.texi > >>> @@ -32942,9 +32942,10 @@ the cache line size. @samp{compat} is the d= efault. > >>> > >>> @opindex mlarge-data-threshold > >>> @item -mlarge-data-threshold=3D@var{threshold} > >>> -When @option{-mcmodel=3Dmedium} is specified, data objects larger th= an > >>> -@var{threshold} are placed in the large data section. This value mu= st be the > >>> -same across all objects linked into the binary, and defaults to 6553= 5. > >>> +When @option{-mcmodel=3Dmedium} or @option{-mcmodel=3Dlarge} is spec= ified, data > >>> +objects larger than @var{threshold} are placed in large data section= s. This > >>> +value must be the same across all objects linked into the binary, an= d defaults > >>> +to 65535. > >> > >> Where's the "must be the same" requirement coming from? > > > > It's an existing requirement. I think it may be related to discouragin= g > > different COMDAT sections names due to different -mlarge-data-threshold= =3D. > > I don't think it makes sense but did not feel strongly dropping it. > > > > Happy to drop the requirement if I revise this patch. > > I understand that this isn't something you introduce, but it still stuck > me as odd. Therefore I thought I'd suggest to take the opportunity to at > least soften the language, unless of course there's a real reason behind > it. Dropping "This value must be the same across all objects linked into the binary" looks good to me. > >> As to the default - to remain compatible with earlier versions, should= n't > >> large model code default to "infinity"? > >> > >> Jan > > > > I have thought about this compatibility need and feel that it is very > > unlikly to be needed. GNU ld has supported large data sections since > > 2005 > > (https://sourceware.org/git/?p=3Dbinutils-gdb.git;a=3Dcommit;h=3D3b2275= 3a67cf616514de804ef6d5ed5e90a7d883). > > Users' programs with the internal linker scripts will still be working > > and -fdata-sections sections will be combined. > > Well, the concern clearly is about custom scripts. Imo ... > > > First, -mcmodel=3Dlarge use cases are rare enough. Rare perhaps > > -mcmodel=3Dlargel was considered theoretic excercise in > > trying to reach feature completion > > (https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU/m/NNuA0P7pAQAJ), > > without this patch -mcmodel=3Dlarge object files don't interract well w= ith > > existing -mcmodel=3Dsmall object files. > > ... the more exotic a project, the more likely it is that they're using > custom scripts. > > > Moreover, if a user expects a specific section prefix with > > -mcmodel=3Dlarge, that's a brittle assumption. I think it's fair to say > > that the fault is on the user side and GCC doesn't need to work around > > their issues. > > I guess I don't really see what you base this on. Without any special > options, expecting data to end up in .data/.bss/.rodata (and variants > thereof) looks like quite reasonable an assumption to me. > > Jan Making -mlarge-data-threshold=3D default value for -mcmodel=3D{medium,large} seems quite odd to me. The default value is 65536, which is larger than most data objects that we may encounter in practice. I want to investigate how often users use -mcmodel=3Dlarge but it is quite difficult. Many are for AIX and/or powerpc. I have tried to be considerate but I am not sure we have users in the intersection of the three sets: -mcmodel=3Dlarge, data objects larger than 65536, using linker script in a way that orphan sections .ldata will cause trouble. --=20 =E5=AE=8B=E6=96=B9=E7=9D=BF