Message ID | 767f8ddc835151d62ce825b8fe7b2ff7b4e3d2e6.camel@xry111.site |
---|---|
State | New, archived |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6a10:b5d6:b0:2b9:3548:2db5 with SMTP id v22csp222360pxt; Wed, 27 Jul 2022 00:08:01 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sGi/8mTcPQ4frSyQtF+NkBIkEMMVV4FktJJ+E1+txXg3c01XzdeQhqrIgUmL3fc3/F09Db X-Received: by 2002:a17:906:8a4a:b0:72b:5b23:3065 with SMTP id gx10-20020a1709068a4a00b0072b5b233065mr17151368ejc.557.1658905681436; Wed, 27 Jul 2022 00:08:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658905681; cv=none; d=google.com; s=arc-20160816; b=ng68r2zL9uWTlC55nfutDJxp2B8yndz0CTDZ/1+/kEyYmh8InF1b9aYGwHSJ6Th8Si ZIc85GRtt1bVAZuUTQj451biWaTZVzxIOTO3KEW79XsY+P+vx3nkuI5jQCUtYOIc/qVL hMBbbfgurwAiAtevSQEb3m5G15XjG2Kn33k5d6wTDZvg7oKlPvx8C8TRXt++8vpJDPQF bo3DvjwxvH6Sx3am1EnVi8qNNepSn8NSz2Ez6QSAM+vIDpZpts/KbIH0+T4S20Lnbh1I jOJj/uXR09Tloe/tta/WCY/uI/7/MCmtFt264qKL51d92QAGEVvzuqsoVu67JPt/ihoc xRCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:cc:reply-to:from:list-subscribe:list-help :list-post:list-archive:list-unsubscribe:list-id:precedence :mime-version:user-agent:content-transfer-encoding:date:to:subject :message-id:dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=wOjFjnXU2K2Q/4Qyg+nHUa1KEb76PWXevMSJW8R/HgE=; b=nPq5nZ/GwtVCTlRKLhKR0dhVDvrdwQTlXSUPdaaKHjD8NFI0NmbIrG9BZrIt/PLT14 Kf2ubvazuFiGXP5D/lBCs9XXVjjcwOmTl24lwupDNdL6IoIJxNgmdHNI8xJ+1opiRsKi fqUvmGs1Sf6Srxqc+hBosBOzcecGIMYQref3QCS5BZkedKkSNWEJXxThohQN070GTTuu fmqMY4Eo/B1H4A3Dx37BdrtpBSTK2JzrnvOy5BnKwZCAgw7UkWqwGycpa/6r+ud+FFEi LBzn3kx2EKRTfh9xG8EKE4jJjXscnaGYoEUFXpD7dO3jiz82c/W5RXxJQKT2naSycSQu CerA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=juBMeZpF; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id dd15-20020a1709069b8f00b00726a885d35bsi20132693ejc.811.2022.07.27.00.08.01 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Jul 2022 00:08:01 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=juBMeZpF; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 15A033857433 for <ouuuleilei@gmail.com>; Wed, 27 Jul 2022 07:08:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 15A033857433 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1658905680; bh=wOjFjnXU2K2Q/4Qyg+nHUa1KEb76PWXevMSJW8R/HgE=; h=Subject:To:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=juBMeZpFEksh5ULyh/al9WRviIy029WrU/Xy8LTfsiI4CMrsUbjV7SD+5RTDehyW5 mbENVh94bCET/GAvkvfWUSnIb+T4ZfyqBXHXpCi8A07pNdrS0/ARSAY/TkCW8ImuQO MYXlf92zi8/SGMcrTLrTOS0CW6Vw2oXUURqYZRyg= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from xry111.site (xry111.site [IPv6:2001:470:683e::1]) by sourceware.org (Postfix) with ESMTPS id 5A8D03857429 for <gcc-patches@gcc.gnu.org>; Wed, 27 Jul 2022 07:07:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5A8D03857429 Received: from [IPv6:240e:358:1119:7700:dc73:854d:832e:3] (unknown [IPv6:240e:358:1119:7700:dc73:854d:832e:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id AADA9667AD; Wed, 27 Jul 2022 03:07:09 -0400 (EDT) Message-ID: <767f8ddc835151d62ce825b8fe7b2ff7b4e3d2e6.camel@xry111.site> Subject: [PATCH] LoongArch: document -m[no-]explicit-relocs To: Lulu Cheng <chenglulu@loongson.cn>, gcc-patches@gcc.gnu.org Date: Wed, 27 Jul 2022 15:06:59 +0800 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.3 MIME-Version: 1.0 X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FROM_SUSPICIOUS_NTLD, FROM_SUSPICIOUS_NTLD_FP, GIT_PATCH_0, LIKELY_SPAM_FROM, PDS_OTHER_BAD_TLD, SPF_HELO_PASS, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Xi Ruoyao via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Xi Ruoyao <xry111@xry111.site> Cc: xuchenghua@loongson.cn, Wang Xuerui <i@xen0n.name> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1739488683905834480?= X-GMAIL-MSGID: =?utf-8?q?1739488683905834480?= |
Series |
LoongArch: document -m[no-]explicit-relocs
|
|
Commit Message
Xi Ruoyao
July 27, 2022, 7:06 a.m. UTC
Document newly introduced -m[no-]explicit-relocs options. Ok for trunk? -- >8 -- gcc/ChangeLog: * doc/invoke.texi: Document -m[no-]explicit-relocs for LoongArch. --- gcc/doc/invoke.texi | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Comments
Hi, On 2022/7/27 15:06, Xi Ruoyao wrote: > Document newly introduced -m[no-]explicit-relocs options. Ok for trunk? > > -- >8 -- > > gcc/ChangeLog: > > * doc/invoke.texi: Document -m[no-]explicit-relocs for > LoongArch. > --- > gcc/doc/invoke.texi | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > index 9a3f2d14c5a..04418f80428 100644 > --- a/gcc/doc/invoke.texi > +++ b/gcc/doc/invoke.texi > @@ -24939,6 +24939,18 @@ global symbol: The data got table must be within +/-8EiB addressing space. > @end itemize > @end table > The default code model is @code{normal}. > + > +@item -mexplicit-relocs > +@itemx -mno-explicit-relocs > +@opindex mexplicit-relocs > +@opindex mno-explicit-relocs > +Generate (do not generate) explicit symbol relocations instead of > +assembler macros. Using explicit relocations can improve code generation. > +GCC detects the capaiblities of the assembler when it is built and sets > +the default to @code{-mexplicit-relocs} if the assembler supports the > +syntax for explicit specification of relocations, and > +@code{-mno-explicit-relocs} otherwise. This option is mostly useful for > +debugging or using an assembler different from build-time. Some text massaging, along with some shameful copying from other (read: RISC-V) -mexplicit-relocs docs... "Use or do not use assembler relocation operators when dealing with symbolic addresses. The alternative is to use assembler macros instead, which may limit optimization. The default value for the option is determined during GCC build-time by detecting corresponding assembler support: @code{-mexplicit-relocs} if said support is present, @code{-mno-explicit-relocs} otherwise. This option is mostly useful for debugging, or interoperation with assemblers different from the build-time one." What do you think? > @end table > > @node M32C Options
在 2022/7/27 下午3:21, WANG Xuerui 写道: > Hi, > > On 2022/7/27 15:06, Xi Ruoyao wrote: >> Document newly introduced -m[no-]explicit-relocs options. Ok for trunk? >> >> -- >8 -- >> >> gcc/ChangeLog: >> >> * doc/invoke.texi: Document -m[no-]explicit-relocs for >> LoongArch. >> --- >> gcc/doc/invoke.texi | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) >> >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi >> index 9a3f2d14c5a..04418f80428 100644 >> --- a/gcc/doc/invoke.texi >> +++ b/gcc/doc/invoke.texi >> @@ -24939,6 +24939,18 @@ global symbol: The data got table must be >> within +/-8EiB addressing space. >> @end itemize >> @end table >> The default code model is @code{normal}. >> + >> +@item -mexplicit-relocs >> +@itemx -mno-explicit-relocs >> +@opindex mexplicit-relocs >> +@opindex mno-explicit-relocs >> +Generate (do not generate) explicit symbol relocations instead of >> +assembler macros. Using explicit relocations can improve code >> generation. >> +GCC detects the capaiblities of the assembler when it is built and sets >> +the default to @code{-mexplicit-relocs} if the assembler supports the >> +syntax for explicit specification of relocations, and >> +@code{-mno-explicit-relocs} otherwise. This option is mostly useful >> for >> +debugging or using an assembler different from build-time. > > Some text massaging, along with some shameful copying from other > (read: RISC-V) -mexplicit-relocs docs... > > "Use or do not use assembler relocation operators when dealing with > symbolic addresses. The alternative is to use assembler macros > instead, which may limit optimization. > > The default value for the option is determined during GCC build-time > by detecting corresponding assembler support: @code{-mexplicit-relocs} > if said support is present, @code{-mno-explicit-relocs} otherwise. > This option is mostly useful for debugging, or interoperation with > assemblers different from the build-time one." > > What do you think? > >> @end table >> @node M32C Options I agree with wangxuerui's idea. The same parameter and the same description information can reduce the user's time to learn how to use this parameter.
On Wed, 2022-07-27 at 16:47 +0800, Lulu Cheng wrote: > > "Use or do not use assembler relocation operators when dealing with > > symbolic addresses. The alternative is to use assembler macros > > instead, which may limit optimization. > > > > The default value for the option is determined during GCC build- > > time by detecting corresponding assembler support: @code{-mexplicit- > > relocs} if said support is present, @code{-mno-explicit-relocs} > > otherwise. This option is mostly useful for debugging, or > > interoperation with assemblers different from the build-time one." > > > I agree with wangxuerui's idea. > The same parameter and the same description information can reduce the > user's time to learn how to use this parameter. I agree it's better than my origin paragraph. If you agree I'll commit it with Xuerui as the commit author.
在 2022/7/27 下午5:15, Xi Ruoyao 写道: > On Wed, 2022-07-27 at 16:47 +0800, Lulu Cheng wrote: > >>> "Use or do not use assembler relocation operators when dealing with >>> symbolic addresses. The alternative is to use assembler macros >>> instead, which may limit optimization. >>> >>> The default value for the option is determined during GCC build- >>> time by detecting corresponding assembler support: @code{-mexplicit- >>> relocs} if said support is present, @code{-mno-explicit-relocs} >>> otherwise. This option is mostly useful for debugging, or >>> interoperation with assemblers different from the build-time one." >>> >> I agree with wangxuerui's idea. >> The same parameter and the same description information can reduce the >> user's time to learn how to use this parameter. > I agree it's better than my origin paragraph. > > If you agree I'll commit it with Xuerui as the commit author. > I have no opinion if wangxuerui agrees.
On 2022/7/27 17:28, Lulu Cheng wrote: > > > 在 2022/7/27 下午5:15, Xi Ruoyao 写道: >> On Wed, 2022-07-27 at 16:47 +0800, Lulu Cheng wrote: >> >>>> "Use or do not use assembler relocation operators when dealing with >>>> symbolic addresses. The alternative is to use assembler macros >>>> instead, which may limit optimization. >>>> >>>> The default value for the option is determined during GCC build- >>>> time by detecting corresponding assembler support: @code{-mexplicit- >>>> relocs} if said support is present, @code{-mno-explicit-relocs} >>>> otherwise. This option is mostly useful for debugging, or >>>> interoperation with assemblers different from the build-time one." >>>> >>> I agree with wangxuerui's idea. >>> The same parameter and the same description information can reduce the >>> user's time to learn how to use this parameter. >> I agree it's better than my origin paragraph. >> >> If you agree I'll commit it with Xuerui as the commit author. >> > > I have no opinion if wangxuerui agrees. Either is OK (if you really think the commit is effectively rewritten by me), thanks.
On Wed, 2022-07-27 at 17:57 +0800, WANG Xuerui wrote: > On 2022/7/27 17:28, Lulu Cheng wrote: > > > > > > 在 2022/7/27 下午5:15, Xi Ruoyao 写道: > > > On Wed, 2022-07-27 at 16:47 +0800, Lulu Cheng wrote: > > > > > > > > "Use or do not use assembler relocation operators when dealing with > > > > > symbolic addresses. The alternative is to use assembler macros > > > > > instead, which may limit optimization. > > > > > > > > > > The default value for the option is determined during GCC build- > > > > > time by detecting corresponding assembler support: @code{-mexplicit- > > > > > relocs} if said support is present, @code{-mno-explicit-relocs} > > > > > otherwise. This option is mostly useful for debugging, or > > > > > interoperation with assemblers different from the build-time one." > > > > > > > > > I agree with wangxuerui's idea. > > > > The same parameter and the same description information can reduce the > > > > user's time to learn how to use this parameter. > > > I agree it's better than my origin paragraph. > > > > > > If you agree I'll commit it with Xuerui as the commit author. > > > > > > > I have no opinion if wangxuerui agrees. > Either is OK (if you really think the commit is effectively rewritten by > me), thanks. Pushed r13-1859.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 9a3f2d14c5a..04418f80428 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -24939,6 +24939,18 @@ global symbol: The data got table must be within +/-8EiB addressing space. @end itemize @end table The default code model is @code{normal}. + +@item -mexplicit-relocs +@itemx -mno-explicit-relocs +@opindex mexplicit-relocs +@opindex mno-explicit-relocs +Generate (do not generate) explicit symbol relocations instead of +assembler macros. Using explicit relocations can improve code generation. +GCC detects the capaiblities of the assembler when it is built and sets +the default to @code{-mexplicit-relocs} if the assembler supports the +syntax for explicit specification of relocations, and +@code{-mno-explicit-relocs} otherwise. This option is mostly useful for +debugging or using an assembler different from build-time. @end table @node M32C Options