From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70284 invoked by alias); 26 Jun 2018 20:02:33 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 70251 invoked by uid 89); 26 Jun 2018 20:02:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:d5d1037, Hx-languages-length:1902 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Jun 2018 20:02:32 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 798403082A29; Tue, 26 Jun 2018 20:02:30 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-5.rdu2.redhat.com [10.10.112.5]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5FA67100191C; Tue, 26 Jun 2018 20:02:29 +0000 (UTC) Subject: Re: Question regarding preventing optimizing out of register in expansion To: "Peryt, Sebastian" , Peter Bergner Cc: "gcc@gcc.gnu.org" References: <17623B198193D741876BD81A6E3AE5AD3C7B98EE@irsmsx111.ger.corp.intel.com> <568618ea-c8e3-c44a-5b48-89a8623bc29d@acm.org> <17623B198193D741876BD81A6E3AE5AD3C7BE10D@irsmsx111.ger.corp.intel.com> <17623B198193D741876BD81A6E3AE5AD3C7BE705@irsmsx111.ger.corp.intel.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: Date: Wed, 27 Jun 2018 10:26:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <17623B198193D741876BD81A6E3AE5AD3C7BE705@irsmsx111.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00273.txt.bz2 On 06/26/2018 01:20 PM, Peryt, Sebastian wrote: >> Subject: Re: Question regarding preventing optimizing out of register in >> expansion >> >> On 6/26/18 4:05 AM, Peryt, Sebastian wrote: >>> With some changes simplified implementation of my expansion is as follows: >>> tmp_op0 = gen_reg_rtx (mode); >>> emit_move_insn (tmp_op0, op0); >> >> You set tmp_op0 here, and then.... >> >> >>> emit_insn (gen_rtx_SET (tmp_op0, reg)); >> >> You set it again here without ever using it above, so it's dead code, which >> explains why it's removed. > > Oh.... My bad - I oversimplified my code. Now I can see it. > > This should be more appropriate: > tmp_op0 = gen_reg_rtx (mode); > emit_move_insn (tmp_op0, op0); > tmp_op1 = gen_reg_rtx (mode); > emit_move_insn (tmp_op1, op1); > > // This is important part > reg = gen_rtx_REG(wide_mode, XMM2_REG); > op3 = gen_rtx_PLUS (mode, tmp_op1, GEN_INT (128)); > emit_insn (gen_rtx_SET (reg, op3)); > > emit_insn (gen_myinsn(op2, reg)); > > op3 = gen_rtx_PLUS (mode, tmp_op0, GEN_INT (128)); > emit_insn (gen_rtx_SET (op3, reg)); > //// > > Also I'd like to one more time point out that without additional -mavx or -mavx2 > I'm getting expected register moves before and after my instr. With those options > only *after*. This is the part that I don't get especially - why. I don't know the details of what you're doing, but the expansion phase may be trying make operands you provide fit the predicate for expanders or named patterns you're using. It may also be the case that copies are created as a result of other define_expands, etc. The way to figure this out is to note the insn # for the unexpected copy. Then put a breakpoint in emit_insn that is conditional on cur_insn_uid having that value. You can then walk up the callchain and try to ascertain why those copies were made. jeff