From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id 3FEA43858C83 for ; Thu, 18 Aug 2022 13:00:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3FEA43858C83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from [10.20.4.52] (unknown [10.20.4.52]) by localhost.localdomain (Coremail) with SMTP id AQAAf8CxT+DrN_5i790DAA--.19602S2; Thu, 18 Aug 2022 21:00:27 +0800 (CST) Subject: Re: [PATCH v1] LoongArch: Add support code model extreme. To: Xi Ruoyao , gcc-patches@gcc.gnu.org Cc: i@xen0n.name, xuchenghua@loongson.cn References: <20220818100112.142343-1-chenglulu@loongson.cn> From: Lulu Cheng Message-ID: <524ce281-032e-4988-13c5-da8377d4246a@loongson.cn> Date: Thu, 18 Aug 2022 21:00:27 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CM-TRANSID: AQAAf8CxT+DrN_5i790DAA--.19602S2 X-Coremail-Antispam: 1UD129KBjvdXoWrKr45Zry8uF4xGrWDtw1fZwb_yoWftFXE9F yDAFy8Wa90gr4vkF42vFn8XFnrCa4q9ryaqrW0gFsrCr1xJFZ8C398tr95X3W8GF4jgF98 AryIqw43AasavjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb4xYjsxI4VWkKwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAv7VC0I7IYx2IY 67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y4 8IcVAKI48JMx8GjcxK6IxK0xIIj40E5I8CrwCYjI0SjxkI62AI1cAE67vIY487MxkIecxE wVCm-wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14 v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkG c2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4U MIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07beF4iUUU UU= X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, BODY_8BITS, HTML_MESSAGE, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2022 13:00:40 -0000 在 2022/8/18 下午8:52, Xi Ruoyao 写道: > On Thu, 2022-08-18 at 19:49 +0800, Lulu Cheng wrote: >>> I think we can ignore the effect of -fplt if code model is extreme, >>> instead of forcing everyone to explicitly add -fno-plt. The "large" >>> code model of x86_64 also does not limit the address range and it always >>> avoids PLT (even if someone adds "-fplt" explicitly). >>     Do you mean that if cmodel=extreme, >>       then add -fno-plt by default? > Yes, we should use -fno-plt as the default for cmodel=extreme. > > x86_64 silently ignores -fplt for cmodel=large (their "large" is like > our "extreme"), but perhaps it's better for us to just report an error > if someone uses "-mcmodel=extreme -fplt" explicitly (if possible, I'm > not sure if we can determine whether -fplt is explicitly given in the > backend code). > I thought if using -mcmodel=extreme and -fplt at the same time we could add a warning here and inform the user that we changed to noplt.