From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id AF0443858C50 for ; Sat, 29 Apr 2023 18:03:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AF0443858C50 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x429.google.com with SMTP id d2e1a72fcca58-63b620188aeso1387249b3a.0 for ; Sat, 29 Apr 2023 11:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682791399; x=1685383399; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=HVb3Vag6+CdlUTZMlBcfnu768BG0Y+9XQxab9oSW9u0=; b=mW4/OMncf1rTL2lSEESl9YKBsX0xhiAu1OVaCv4vzMl+sZWpGq/gbI1USRcHGCec9c Ge5OWy83dYShdBhoMrGMgHTLEixh4rxFEzObYaCEUR3LMVI1XiJcSitXsysXBJdQsQ+B /ytGtHQOQxZMb293fLg6/2Nrub70x4vmZn5qcwCykjmYJwLTNIQ2aI0UaHexH4KN7qb5 A4CbmAGJPLhQIt8CmlPXXsm5KbTGpqI4SIZPllecLM/jBECoH5xQYBMZE9j3xSV3PvHq mHDZTjidUzypNICF7FLsAZsMhjJZCTYyT1vU/VJzN2F8az/2ThN5BfvRH6o49kuJnTnJ 1krA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682791399; x=1685383399; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HVb3Vag6+CdlUTZMlBcfnu768BG0Y+9XQxab9oSW9u0=; b=XcqJ+un5Eki9Pw+rPt810R12rKYg8cMorPmK+0gq4a7t/Yhq3dlj3n8uJ86jRkDCmb K9jOlJePEGGw1cMkAy6rplmoVCO/6mBT+ivP7jK2+9JAFd+50+QP/YaotV8BvVryd5tN +jFt1gNfNTVSOn6r8Rn0eDJ+2ZZ7Wj++rUuZ9PKdStAeSrguMHVFiMV3elTydadoATJR F+eZfckVf+JfUY4sv4vzid4W6yiIJzbAnYpgnU6xTuWpTAUTcIoJJJkm+2n9GWLd2twW hzO9IMVlygXtloN1RxtnX6E3AI4uPN41t2OYbYwMWQ8OIYK3QP4gma+6ZkbXygBL8eU0 vT4g== X-Gm-Message-State: AC+VfDyjUDWGRmihF6F0VSk2vkr9ut6TX9wgyHSe5twcHIpRr0SJtmwf iQq8duoviuOuMeVbuBPcymg= X-Google-Smtp-Source: ACHHUZ6SYsXV5Q1iEusvIh2pwgbum0ZTQa1+/xz4T01lchBoHu6QI//sCEbj8xVRpG+vcJPB0X4i/Q== X-Received: by 2002:a05:6a00:190d:b0:636:e52f:631e with SMTP id y13-20020a056a00190d00b00636e52f631emr12520439pfi.1.1682791399416; Sat, 29 Apr 2023 11:03:19 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::99f? ([2601:681:8600:13d0::99f]) by smtp.gmail.com with ESMTPSA id j9-20020a056a00234900b0063d3d776910sm17237495pfj.138.2023.04.29.11.03.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Apr 2023 11:03:18 -0700 (PDT) Message-ID: <8af8ca8b-858d-1d54-295c-fc050bed9062@gmail.com> Date: Sat, 29 Apr 2023 12:03:17 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH] reload: Handle generating reloads that also clobbers flags Content-Language: en-US To: Hans-Peter Nilsson Cc: gcc-patches@gcc.gnu.org References: <20230215153432.0663D2042E@pchp3.se.axis.com> <37af8f44-3189-2371-fd50-6c201c339260@gmail.com> <20230418141217.CF9FF203FA@pchp3.se.axis.com> From: Jeff Law In-Reply-To: <20230418141217.CF9FF203FA@pchp3.se.axis.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: On 4/18/23 08:12, Hans-Peter Nilsson wrote: >> 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. Ah, yes, thanks for the reminder that there's multiple approaches here. If I cared enough it'd probably make more sense at this point to expose cc0 early on the H8 as doing so would allow easier codegen for overflow tests which in turn could significantly speed up the testsuite. OK for the trunk. jeff