From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 5FCF8386F011 for ; Fri, 23 Oct 2020 07:35:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5FCF8386F011 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bebbosoft.de Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=s.franke@bebbosoft.de Received: from serveronline.org ([78.46.86.77]:46700 helo=bebbosoft.de) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1kVrbj-0003tt-AL for gcc-help@gcc.gnu.org; Fri, 23 Oct 2020 03:35:29 -0400 Received: from ZETRA (pd9e55a9a.dip0.t-ipconnect.de [217.229.90.154]) by serveronline.org (BEJY V1.6.12-SNAPSHOT (c) 2000-2019 by BebboSoft, Stefan "Bebbo" Franke, all rights reserved) with SMTP id 17554622925639be92a1303bd8d from s.franke@bebbosoft.de for gcc-help@gcc.gnu.org; Fri, 23 Oct 2020 08:35:20 +0100 Reply-To: From: "Stefan Franke" To: "'gcc-help'" References: <20201022222438.GX2672@gate.crashing.org> <82fed76c-e343-a155-4b3d-ef8ab07d2baf@redhat.com> <734be852-33ed-ee19-88a9-99a5905db5cf@blueice.be> In-Reply-To: <734be852-33ed-ee19-88a9-99a5905db5cf@blueice.be> Subject: AW: How to recognize registers after reload ?. Date: Fri, 23 Oct 2020 09:35:20 +0200 Message-ID: <0cd001d6a90f$0fd96f80$2f8c4e80$@bebbosoft.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIxzmXTnvo9X6d5gf7NnIZYLuROuAJdkBsFAs+x5/EB1POIfgG94lLHqKh/iGA= Content-Language: de Received-SPF: pass client-ip=78.46.86.77; envelope-from=s.franke@bebbosoft.de; helo=bebbosoft.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/23 03:35:20 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=4.1 required=5.0 tests=BAYES_50, KAM_DMARC_STATUS, RCVD_IN_BARRACUDACENTRAL, SPF_FAIL, SPF_HELO_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 07:35:31 -0000 > -----Urspr=C3=BCngliche Nachricht----- > Von: Gcc-help Im Auftrag von Henri > Cloetens > Gesendet: Freitag, 23. Oktober 2020 09:29 > An: Jeff Law ; Segher Boessenkool > > Cc: gcc-help > Betreff: Re: How to recognize registers after reload ?. >=20 > Hello Segher, Jeff, >=20 > - The machine is indeed such that for each operation there is only one > non-register operand possible. > - Take a first example, to describe the problem with the combine: > void set_to_one(int *a) > { > *a =3D 1 ; > } >=20 > In the machine, this becomes: >=20 > R30 =3D 1 // move immediate to register > [R20] =3D R30 // move to *a > return >=20 > Now, to get this, there is not one movsi - pattern, because if there = is only > one, combine will combine both moves into something like [R20] =3D 1 = and this > does not exist, and combine crashes. So, there are 2 moves: > /movesi_internal_fromreg/ (moving from a register to memory or = register) > /movesi_internal_toreg/ (moving from immediate, memory, register to > register). >=20 > This is all nice and fine, until the reload step. In case the number = of internal > registers is exceeded, stuff needs to go on the stack. Now, suppose I = have > the operation >=20 > R30 =3D 1 >=20 > and the compiler wants to put R30 on the stack, it sees this is not = possible, > and will make a helper move : >=20 > R30 =3D 1 (old one) > R100 =3D R30 >=20 > and then, it will try to put R100 on the stack. Now, to do the move, > R100 =3D R30, it calls the > /movsi/ pattern in the machine description. Only, it declares in the = RTX > R100 as a register operand, > which it is not, or not entirely. It is a stack operand, but my = /define_expand > movsi/ recognizes it as a register operand, end emits > /movesi_internal_toreg/, while it should emit = /movesi_internal_fromreg/, > and the whole system ends in an endless loop. > To solve this decently, I need to find in the /define_expand movsi/ if > R100 is a stack operand or not. > There is one way, that is to implement TARGET_SECONDARY_RELOAD, have > that parse all the arguments, put it in an operand database, and have > /define_expand movsi/ interrogate this database. Now, I will only do = that if > there is no other option. >=20 > Best Regards, >=20 > Henri. > > Henri, it seems your define_expand for movsi is too narrow. It should accept = all mandatory forms. The distinction - to register/memory - should be = done in movsi itself. There is also no need for a database to = distinguish. Regards Stefan