From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id E0AC23854561 for ; Mon, 28 Nov 2022 09:41:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E0AC23854561 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.96,200,1665475200"; d="scan'208";a="87942239" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 28 Nov 2022 01:41:49 -0800 IronPort-SDR: wRQqz0NJ57CS1IB6nBFj82Y3fbOF/I54QFfjZQ9U6AXHRrjQTXPEDiWIe9FE1QAqNw8MKVotFo cuiyUB9Bj38dMNMjd4y7JVMSos/8iIT5iT+ZU7oEQl5VWRGH/MDm8fbe+Rq8ZdwQxuBM7146dN 5B1Ya0PPKIfaNHQdYB1UU3xrUev9n0n3um4/uoIMxgtb/EPwanLj/dSDakHjqVw5stw7sjwgEc /13DBy9Bb3Fz0aoY7T0PfUxTUoXNTFuLVmRUTc2sh6HX9g2nJVgW8nFNCY4WLmXzwC/bhY6saC s2c= Message-ID: Date: Mon, 28 Nov 2022 09:41:44 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [Patch] gcn: Fix __builtin_gcn_first_call_this_thread_p Content-Language: en-GB To: Tobias Burnus , gcc-patches References: <54ee69be-7101-c4e0-fbca-3c7c3f1101b8@codesourcery.com> From: Andrew Stubbs In-Reply-To: <54ee69be-7101-c4e0-fbca-3c7c3f1101b8@codesourcery.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-08.mgc.mentorg.com (139.181.222.8) To svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,BODY_8BITS,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,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 List-Id: On 28/11/2022 07:40, Tobias Burnus wrote: > It turned out that cprop cleverly propagated the unspec_volatile > to the preceding (pseudo)register, permitting to remove the > 'set (s0) (pseudoregister)' at -O2.  Unfortunately, it does > matter whether the assignment is done to 's2' (previously: pseudoregister) > or to s1. – Just having a hard register is not enough ... > > Solution: Use USE (alias gen_rtx_USE) instead. > > Additionally, I removed the s0 modification (that should lead to the > unchanged result) > by adding 'gcn_operand_part (DImode, reg, 1)' and then working with > SImode. Result: > >   if (__builtin_gcn_first_call_this_thread_p()) >     x = 42; > > becomes now (with -O2) the following; the builtin code is up to to (and > including) > '.L2', the rest is the 'if' and 'x=42': > >         s_lshr_b32      s2, s1, 16 >         s_cmpk_lg_u32   s2, 12345 >         s_mov_b32       s12, scc >         s_mov_b32       vcc_lo, scc >         s_mov_b32       vcc_hi, 0 >         s_cbranch_vccz  .L2 >         s_and_b32       s2, s1, 65535   (= 0xFFFF) >         s_or_b32        s1, s2, 809041920 (= 0x30390000 = (12345 << 16)) > .L2: >         s_getpc_b64     s[2:3] >         s_add_u32       s2, s2, x@rel32@lo+4 >         s_addc_u32      s3, s3, x@rel32@hi+4 >         s_mov_b32       vcc_lo, s12 >         s_mov_b32       vcc_hi, 0 >         s_cbranch_vccz  .L3 >         s_mov_b32       s12, 42 >         v_writelane_b32 v0, s12, 0 >         s_mov_b64       exec, 1 >         global_store_dword      v1, v0, s[2:3] > .L3: > > > OK for mainline? OK. Andrew