From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22327 invoked by alias); 24 Jan 2018 15:36:57 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 22075 invoked by uid 89); 24 Jan 2018 15:36:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Jan 2018 15:36:55 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-MBX-04.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1eeN6a-0002Rq-NO from Tom_deVries@mentor.com ; Wed, 24 Jan 2018 07:36:52 -0800 Received: from [137.202.13.177] (137.202.0.87) by SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 24 Jan 2018 15:36:49 +0000 Subject: Re: [PATCH, 2/2][nvptx, PR83589] Workaround for branch-around-nothing JIT bug To: Jakub Jelinek CC: GCC Patches , Richard Biener References: <34fb1d00-dc5d-04f2-d601-ee6fe710ac3b@mentor.com> <20180124110305.GZ2063@tucnak> <4909fc79-df36-16b1-78d0-e9cd9da4080e@mentor.com> <20180124140703.GB2063@tucnak> From: Tom de Vries Message-ID: Date: Wed, 24 Jan 2018 16:03:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180124140703.GB2063@tucnak> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) X-SW-Source: 2018-01/txt/msg02030.txt.bz2 On 01/24/2018 03:07 PM, Jakub Jelinek wrote: > On Wed, Jan 24, 2018 at 02:56:28PM +0100, Tom de Vries wrote: >> +#if WORKAROUND_PTXJIT_BUG_2 >> +/* Variant of pc_set that only requires JUMP_P (INSN) if STRICT. This variant >> + is needed in the nvptx target because the branches generated for >> + parititioning are NONJUMP_INSN_P, not JUMP_P. */ >> + >> +static rtx >> +nvptx_pc_set (const rtx_insn *insn, bool strict = true) >> +{ >> + rtx pat; >> + if ((strict && !JUMP_P (insn)) >> + || (!strict && !INSN_P (insn))) >> + return NULL_RTX; >> + pat = PATTERN (insn); >> + >> + /* The set is allowed to appear either as the insn pattern or >> + the first set in a PARALLEL. */ >> + if (GET_CODE (pat) == PARALLEL) >> + pat = XVECEXP (pat, 0, 0); > > This could have been single_set. > This is just a copy of pc_set in jump.c, with the strict parameter added. It's possible that we can use single_set in pc_set in jump.c. But there are subtle differences: - current pc_set allows a second non-dead set in parallel - single_set doesn't allow second non-dead set in parallel I don't know whether this difference is significant or not. >> + if (!x) >> + return NULL_RTX; >> + x = SET_SRC (x); >> + if (GET_CODE (x) == LABEL_REF) >> + return x; >> + if (GET_CODE (x) != IF_THEN_ELSE) >> + return NULL_RTX; >> + if (XEXP (x, 2) == pc_rtx && GET_CODE (XEXP (x, 1)) == LABEL_REF) >> + return XEXP (x, 1); >> + if (XEXP (x, 1) == pc_rtx && GET_CODE (XEXP (x, 2)) == LABEL_REF) >> + return XEXP (x, 2); >> + return NULL_RTX; > > And this looks like condjump_label. This is just a copy of condjump_label in jump.c, with the strict parameter added. > What are the nvptx conditional jumps > that aren't JUMP_INSN and why? That looks like a bad idea. OpenACC has different execution modes: - gang redundant vs gang partitioned - worker single vs worker partitioned - vector single vs vector partitioned The transitions between the different modes are represented by: - nvptx_fork - nvptx_forked - nvptx_join - nvptx_joined until pass_machine_reorg. In pass_machine_reorg, they are expanded into more detailed operations implementing state propagation and neutering code for single mode. The neutering code consists of branch-around code, which uses these conditional jumps that are not JUMP_INSN. My assumption is that this is done in order to make the compiler behave conservatively with these jumps. I'm not sure if this is related to one or more passes after reorg, or if this is just defensive programming. I could try to change these into JUMP_INSN in stage1, and see how that goes. > Otherwise, there is also JUMP_LABEL (insn)... Right, that one requires a JUMP_INSN. Thanks, - Tom