From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71860 invoked by alias); 9 Nov 2018 10:21:00 -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 70928 invoked by uid 89); 9 Nov 2018 10:20:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:CAKdteOa4RoWrn, H*f:sk:5508248, H*f:sk:a27db9c, H*f:sk:c9cf3c7 X-HELO: foss.arm.com Received: from usa-sjc-mx-foss1.foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Nov 2018 10:20:58 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5B242A78; Fri, 9 Nov 2018 02:20:56 -0800 (PST) Received: from e120077-lin.cambridge.arm.com (e120077-lin.cambridge.arm.com [10.2.206.194]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E54F33F718; Fri, 9 Nov 2018 02:20:54 -0800 (PST) Subject: Re: [PATCH] combine: Do not combine moves from hard registers To: Segher Boessenkool , Renlin Li Cc: Jeff Law , Christophe Lyon , gcc Patches , bergner@linux.ibm.com References: <20181023122855.GI5205@gate.crashing.org> <20181023222645.GT5205@gate.crashing.org> <20181102230320.GV5994@gate.crashing.org> <20181102235422.GW5994@gate.crashing.org> <55082488-6f99-9ff9-b784-070495905d13@redhat.com> <20181107230226.GL5994@gate.crashing.org> From: "Richard Earnshaw (lists)" Openpgp: preference=signencrypt Message-ID: Date: Fri, 09 Nov 2018 10:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181107230226.GL5994@gate.crashing.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2018-11/txt/msg00689.txt.bz2 On 07/11/2018 23:02, Segher Boessenkool wrote: > Hi! > > On Mon, Nov 05, 2018 at 06:16:16PM +0000, Renlin Li wrote: >> Sorry, this is not correct. Instructions scheduled between x and x+1 >> directly use hard register r1. >> It is not IRA/LRA assigning r1 to the operands. >> >> >> To reproduce this particular case, you could use: >> cc1 -O3 -marm -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp >> gcc.c-torture/execute/builtins/memcpy-chk.c >> >> This insn is been splitted. >> >> (insn 152 150 154 11 (set (mem/c:QI (plus:SI (reg/f:SI 266) >> (const_int 24 [0x18])) [0 MEM[(void *)&p + 20B]+4 S1 A32]) >> (reg:QI 1 r1)) "memcpy-chk-reduce.c":48:3 189 {*arm_movqi_insn} >> (expr_list:REG_DEAD (reg:QI 1 r1) >> (nil))) > > Okay, I see what is going on. The arm port often expands movmem to use > hard registers (so that it can use load/store multiple?). This does not > work well with scheduling and RA, and this combine feature makes it worse. > Yes, GCC doesn't have any way of describing the constraint "I need registers in ascending order of register number". So the only way around this is to nail down which registers are used. In practice this has worked pretty well for the last 20 years or so. R. > I don't know what to do about it in combine. > > > Segher >