From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id 89E093858D1E for ; Tue, 18 Apr 2023 13:43:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 89E093858D1E 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-pl1-x632.google.com with SMTP id d9443c01a7336-1a6f0d8cdfeso6782415ad.2 for ; Tue, 18 Apr 2023 06:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681825423; x=1684417423; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=/lW6vjiHje9Q1c7S1m8KgZ62dK2vfRLK/8k7vV4DRTI=; b=Z5KTzxIsvh3xomv8pNInAqdxNEkiPM7gu+C51Xjp+Bdf//aI+3nQ9RwJHcXAAI1uBE 1J5nw96vGNxoEui1mM6yFEb8YF+ILaohS5/3ZLRzFMJfS97e/rUmyi5UrTZuUOn0W1/5 DrA/w9RcXSHu4K/Z7VmDLGaOO0TtT9spxSToYwWtToq3itAWembrHS9nKML4UE9wVPsK 87+hpGmh/9S1ByV2VlMvPu0NmVsHM6r1ZtpfW2mhlwWLnurQBNR0fk4k2OQatOLYkETM ZpaArijChBY0gZSl3XjuiwwOa9MWics+ptoDOKBsvG7bGm+ZB0Qe3yYPkUTMP3l72aqU 12/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681825423; x=1684417423; h=content-transfer-encoding:in-reply-to:from:references: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=/lW6vjiHje9Q1c7S1m8KgZ62dK2vfRLK/8k7vV4DRTI=; b=dMhJd2k9JVPp+kFY3zmT3XPcq2DyiaVqx6gzMhBGg/TWPntILOnSgjDczS/kIZNzUs N09UC/2ACRK1MoCjD9zigwdPW0BBHZuRndU+0HpWyHpVvi8RLiBH7pfzI1OO31UGGq3a 6SRm68hMbNE3dvVG8IBvZimTQSWfyNNZ4VqaLsndQV1ADIbEx3MxN74JNs7CifrJJ/Yx T0tEq52Fnd19+pDNr/Zvp7CvtzXHu2F0i1J2zLJe/4VSaT6nLedcc+zUG2IR6H74N/Eb 8Y39RtCj+ji9QeiSlFDWyN25EMXP0vLsckxfB4FajZA1vIYZaQ6DVUErJCcxZMx8dV1q WwgQ== X-Gm-Message-State: AAQBX9cc5pRgh6HdFiXlYBIolDYhbxEM6CiX4c+/h5fb0DPrSmCkatJy P3lsCeCIUY0iJr3OYSRBMgE= X-Google-Smtp-Source: AKy350abKHZMmvN75xY5weFWsAP61ZUg3zcxfMQvylXD3CCcOp8sIrjuo0fUY/ONEfbMzXy3dyfyoA== X-Received: by 2002:a17:902:6b4b:b0:1a6:f1f3:e475 with SMTP id g11-20020a1709026b4b00b001a6f1f3e475mr1965186plt.55.1681825423550; Tue, 18 Apr 2023 06:43:43 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id y13-20020a1709029b8d00b001a810871797sm149220plp.38.2023.04.18.06.43.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Apr 2023 06:43:43 -0700 (PDT) Message-ID: <37af8f44-3189-2371-fd50-6c201c339260@gmail.com> Date: Tue, 18 Apr 2023 07:43:41 -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 , gcc-patches@gcc.gnu.org References: <20230215153432.0663D2042E@pchp3.se.axis.com> From: Jeff Law In-Reply-To: <20230215153432.0663D2042E@pchp3.se.axis.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.7 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 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. jeff