From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.axis.com (smtp2.axis.com [195.60.68.18]) by sourceware.org (Postfix) with ESMTPS id 4AF353858D1E for ; Tue, 18 Apr 2023 14:12:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4AF353858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=axis.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=axis.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axis.com; q=dns/txt; s=axis-central1; t=1681827140; x=1713363140; h=from:to:cc:in-reply-to:subject:mime-version: content-transfer-encoding:references:message-id:date; bh=EUygY04+pE+FrbxE7aF85K2w+ELZWMH9hga0G1br5kI=; b=XtR9Cu54S25mjIMF/GxpAYBi2r+i4R6XLXYFmJ0alS2nswS+d8/lZLzS osm8/fP0CvYimQ+sCfdmWp59Z6jGQpjGW3L80z2KWu2k8tpCROCEZsX94 Q2KlxbHH3VVQOnowUhG1O54h/+UHt7wsNvPteQFf4miMbjDSyS3tEb3qb DZJRzSonPfPSz72ZeBALHrsGb7iJXefUbaOk/r7uA/DLGuXTyfcuFu1gW irD1j/OP/kUnpb03nmDnTZjpAhhfu0RGrkCkkhVooOeOZiumh/w0wWUon HtkRuOQcq8F2/vvFroXtUfgqyqjBirqisUAPT4RS79VYGMvbA6tb/OsMs w==; From: Hans-Peter Nilsson To: Jeff Law CC: In-Reply-To: <37af8f44-3189-2371-fd50-6c201c339260@gmail.com> (message from Jeff Law on Tue, 18 Apr 2023 07:43:41 -0600) Subject: Re: [PATCH] reload: Handle generating reloads that also clobbers flags MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT References: <20230215153432.0663D2042E@pchp3.se.axis.com> <37af8f44-3189-2371-fd50-6c201c339260@gmail.com> Message-ID: <20230418141217.CF9FF203FA@pchp3.se.axis.com> Date: Tue, 18 Apr 2023 16:12:17 +0200 X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: > Date: Tue, 18 Apr 2023 07:43:41 -0600 > From: Jeff Law > On 2/15/23 08:34, Hans-Peter Nilsson via Gcc-patches wrote: > > Regtested cris-elf with its LEGITIMIZE_RELOAD_ADDRESS > > disabled, where it regresses gcc.target/cris/rld-legit1.c; > > as expected, because that test guards proper function of its > > LEGITIMIZE_RELOAD_ADDRESS i.e., that there's no sign of > > decomposed address elements. > > > > LRA also causes a similar decomposition (and worse, in even > > smaller bits), but it can create valid insns as-is. > > Unfortunately, it doesn't have something equivalent to > > LEGITIMIZE_RELOAD_ADDRESS so it generates worse code for > > cases where that hook helped reload. > > > > I fear reload-related patches these days are treated like a > > redheaded stepchild and even worse as this one is intended > > for stage 1. Either way, I need to create a reference to > > it, and it's properly tested and has been a help when > > working towards LRA, thus might help other targets: ok to > > install for the next stage 1? > > > > -- >8 -- > > When LEGITIMIZE_RELOAD_ADDRESS for cris-elf is disabled, > > this code is now required for reload to generate valid insns > > from some reload-decomposed addresses, for example the > > (plus:SI > > (sign_extend:SI (mem:HI (reg/v/f:SI 32 [ a ]) [1 *a_6(D)+0 S2 A8])) > > (reg/v/f:SI 33 [ y ])) > > generated in gcc.target/cris/rld-legit1.c (a valid address > > but with two registers needing reload). Now after decc0:ing, > > most SET insns for former cc0 targets need to be a parallel > > with a clobber of the flags register. Such targets > > typically have TARGET_FLAGS_REGNUM set to a valid register. > > > > * reload1.cc (emit_insn_if_valid_for_reload_1): Rename from > > emit_insn_if_valid_for_reload. > > (emit_insn_if_valid_for_reload): Call new helper, and if a SET fails > > to be recognized, also try emitting a parallel that clobbers > > TARGET_FLAGS_REGNUM, as applicable. > BUt isn't it the case that we're not supposed to be exposing the flags > register until after reload? And if that's the case, then why would > this be necessary? Clearly I must be missing something. That "supposed to" is only *one* possible implementation. The one in CRIS - and I believe the preferred one; one I should advocate more - is to *always* expose clobbering of the flags. (I managed to do the CRIS decc0ification transformation without loss of performance. There were much fewer issues with code taking PATTERN (insn) and failing on it being PARALLEL than I had expected, much thanks to use of rtx_single_set.) Think about it: why should the semantics of a valid insn change after a "random" pass? That's almost as crazy as the implied semantics of cc0. brgds, H-P