From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:28:0:1:25:1]) by sourceware.org (Postfix) with ESMTPS id 41C844BA23CB for ; Thu, 7 May 2026 06:47:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 41C844BA23CB Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nefkom.net ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 41C844BA23CB Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2001:a60:0:28:0:1:25:1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778136423; cv=none; b=vYom1LSEsR9yQOSuX7Wixdwrz5iytqG9qaJ6+d9o0AzE+b3qgZfVzpNvC+GUA39oLlKBvjxwfZxI3U//soap571U4P0qJevqrQgQcng8/QMgGrK9JyYlO9Jtz3sfdfcDRxHyaLK5s+axKXZEEuoH5AkJ0uQgmQmUGnWMaQnsNCc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778136423; c=relaxed/simple; bh=7EdfaWp/k6iI7rRAbPzRJmMG58jTGuSpxcuIlbn8i0o=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=WNZhhvB9JbheJZcftqLBKpYWC/5fLkANUsyhfxg0uVTB9KHvYKH+DKxNxukC7vshKE0msjgQC5V57O0ONmAVoqQPDig+IXfqTivAicDLDCsYQl+aT9hQy3n7bHifdMUt+K6ySgCWjcGeD9gAGfhFct9FftBlcp7sdsWiq8TkEJE= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 41C844BA23CB Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by mail-out.m-online.net (Postfix) with ESMTP id 4gB2q963SBz1sGWl; Thu, 7 May 2026 08:47:01 +0200 (CEST) Received: from frontend03.mail.m-online.net (unknown [192.168.6.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4gB2q24L6kz1sGWd; Thu, 7 May 2026 08:46:54 +0200 (CEST) Received: from localhost (dynscan3.mnet-online.de [192.168.6.87]) by mail.m-online.net (Postfix) with ESMTP id 4gB2q23Jfvz1qqll; Thu, 7 May 2026 08:46:54 +0200 (CEST) X-Virus-Scanned: amavis at mnet-online.de Received: from mail.mnet-online.de ([192.168.6.182]) by localhost (dynscan3.mail.m-online.net [192.168.6.87]) (amavis, port 10024) with ESMTP id kW7Np2Kr4t-I; Thu, 7 May 2026 08:46:53 +0200 (CEST) X-Auth-Info: IX+C7msOO9E5rjBZu6rOZUx+ODJmY+TNgh04jhqNRxpYgM/cxFTiu0N1MvmtzyAg Received: from igel.home (aftr-82-135-83-41.dynamic.mnet-online.de [82.135.83.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Thu, 7 May 2026 08:46:53 +0200 (CEST) Received: by igel.home (Postfix, from userid 1000) id 5216B2C16F0; Thu, 7 May 2026 08:46:53 +0200 (CEST) From: Andreas Schwab To: Deng Jianbo Cc: adhemerval.zanella@linaro.org, libc-alpha@sourceware.org, caiyinyu@loongson.cn, i.swmail@xen0n.name, joseph_myers@mentor.com, carlos@redhat.com, xuchenghua@loongson.cn Subject: Re: [PATCH] LoongArch: Optimize math barriers In-Reply-To: <20260507021740.16572-1-dengjianbo@loongson.cn> (Deng Jianbo's message of "Thu, 7 May 2026 10:17:40 +0800") References: <20260507021740.16572-1-dengjianbo@loongson.cn> Date: Thu, 07 May 2026 08:46:53 +0200 Message-ID: <87jytf90o2.fsf@igel.home> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on sourceware.org List-Id: On Mai 07 2026, Deng Jianbo wrote: > The constraints 'frm' used in math_opt_barrier and math_force_eval cause > GCC choose fixed-point registers with lower costs in some cases, because > in LoongArch ira_reg_class_subunion[FP_REGS][GR_REGS] is initialized to > GR_REGS, extra move costs will be added when choosing FP_REGS. This > results in unnecessary instructions to move values between FP_REGS and > GR_REGS. It looks like a bug in GCC (wrong cost calculations) if it generates unnecessary moves when it has more choices. > Most of cases in GLIBC math barriers related macros are invoked with > floating-point type paramters, this patch removes "r" constraints, > allowing GCC to keep values in floating-point registers and avoid the > extra moves. It does not *allow* that, it *forces* gcc to use an fp reg (or memory). What if the value is in a general reg in the first place, wouldn't that result in unnecessary moves? -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."