From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 424AE3858C2A for ; Tue, 12 Dec 2023 12:39:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 424AE3858C2A Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 424AE3858C2A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=89.208.246.23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702384793; cv=none; b=k6VSHGwHo9wSG/em6JTy4w3lyFpdXNuI/IOtqbvQ5jvk0aEVZGzzhF+SeGKeYBnJQBOfyLlNnsAbI77hUgwOD2p5CKO994QxMXTWAO6vIJiTUvXJ+t6iw26969C1gBjlcExCTDhOQtB1ks2jag4Yz5wTHDuvobrRQljjk45DfXE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702384793; c=relaxed/simple; bh=eBnX1oID0m6isgdojGXKmeCLcP4Y+WjJ1QTQcZbc1jA=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=PmlIN1VydIsmoXZKAFHUBAuauaRJFWqeWhNot3Uh95shK2Cln1jbK44FRsESMlofyq/jm0+1VhW2cTWebiFdyJJkceMpr3u1QZNCrhosLEC9WRouUgKnk5OrhKtS5hFZVbxwFNd348nqvGzEiOxO/JjeZcibrEL8vo4L7By9G/M= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1702384789; bh=eBnX1oID0m6isgdojGXKmeCLcP4Y+WjJ1QTQcZbc1jA=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Qz7O8efvowRB4Qt3dIB6bHfKE4FFW0Pv/tt7KeG7pzQ1qJJrcO6EsjbNv7Lgr7pmx bm6BM3XqU40EI7GtHHZ1Ll9JlI/AFCkpuBzS6PWLls7OspcHHZq1R2F1JmGdk6fvtJ 37jrwDsZ94s9G/C6BJtyNoTxfywEcch/T7lxg3+Y= Received: from [127.0.0.1] (unknown [IPv6:2001:470:683e::1]) (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 DA86566F8B; Tue, 12 Dec 2023 07:39:47 -0500 (EST) Message-ID: <0f3923a4e5d6c1c02cc1ae4b3cf4d8079aa3ae87.camel@xry111.site> Subject: Re: [PATCH v2] LoongArch: Define LOGICAL_OP_NON_SHORT_CIRCUIT. From: Xi Ruoyao To: Jiahao Xu , gcc-patches@gcc.gnu.org Cc: i@xen0n.name, chenglulu@loongson.cn, xuchenghua@loongson.cn Date: Tue, 12 Dec 2023 20:39:45 +0800 In-Reply-To: References: <20231212111412.29351-1-xujiahao@loongson.cn> <9161b4d8a1dac816df4359dd4ba378fba2ddb575.camel@xry111.site> Autocrypt: addr=xry111@xry111.site; prefer-encrypt=mutual; keydata=mDMEYnkdPhYJKwYBBAHaRw8BAQdAsY+HvJs3EVKpwIu2gN89cQT/pnrbQtlvd6Yfq7egugi0HlhpIFJ1b3lhbyA8eHJ5MTExQHhyeTExMS5zaXRlPoiTBBMWCgA7FiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQrKrSDhnnEOPHFgD8D9vUToTd1MF5bng9uPJq5y3DfpcxDp+LD3joA3U2TmwA/jZtN9xLH7CGDHeClKZK/ZYELotWfJsqRcthOIGjsdAPuDgEYnkdPhIKKwYBBAGXVQEFAQEHQG+HnNiPZseiBkzYBHwq/nN638o0NPwgYwH70wlKMZhRAwEIB4h4BBgWCgAgFiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwwACgkQrKrSDhnnEOPjXgD/euD64cxwqDIqckUaisT3VCst11RcnO5iRHm6meNIwj0BALLmWplyi7beKrOlqKfuZtCLbiAPywGfCNg8LOTt4iMD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 MIME-Version: 1.0 X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 Tue, 2023-12-12 at 19:59 +0800, Jiahao Xu wrote: > > I guess here the problem is floating-point compare instruction is much > > more costly than other instructions but the fact is not correctly > > modeled yet.=C2=A0 Could you try > > https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640012.html > > where I've raised fp_add cost (which is used for estimating floating- > > point compare cost) to 5 instructions and see if it solves your problem > > without LOGICAL_OP_NON_SHORT_CIRCUIT? > I think this is not the same issue as the cost of floating-point=20 > comparison instructions. The definition of LOGICAL_OP_NON_SHORT_CIRCUIT= =20 > affects how the short-circuit branch, such as (A AND-IF B), is executed,= =20 > and it is not directly related to the cost of floating-point comparison= =20 > instructions. I will try to test it using SPECCPU 2017. The point is if the cost of floating-point comparison is very high, the middle end *should* short cut floating-point comparisons even if LOGICAL_OP_NON_SHORT_CIRCUIT =3D 1. I've created https://gcc.gnu.org/PR112985. Another factor regressing the code is we don't have modeled movcf2gr instruction yet, so we are not really eliding the branches as LOGICAL_OP_NON_SHORT_CIRCUIT =3D 1 supposes to do. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University