From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by sourceware.org (Postfix) with ESMTPS id 990EA3858D28 for ; Thu, 6 Apr 2023 14:53:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 990EA3858D28 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-pj1-x102f.google.com with SMTP id qe8-20020a17090b4f8800b0023f07253a2cso40845479pjb.3 for ; Thu, 06 Apr 2023 07:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680792808; x=1683384808; 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=9P6v0ulEd5hUkW/kwOMqiRt3DRCm5f2H5eZvRs3l8jk=; b=kkToduRrTmE7WFxUvlZM1bMukrivNkSlyG8/vtuvIDXSigyrCv8L15yvyei/vBL3PQ b4kJMeE8xocJXQWy9vNKyPrZUoS/YC5mvGs+ojEPlb/wQC9+IiT0G3O/IM/0d/5b8VCP I44M1u6v9P/h78hrdJdWfzZuusu+tvO9RoDe23wkYJDcOaFJkSk+C/lqP/xgWMDP8YJL 7txzkcpfjXy9zwStMN8Gpl6KUF2HEettoXeE+vRphCQWPRLGDbA88was6h7N5TWNea8U yEmAeE1zkE6wUcytssVTcrghJhimJGTnE9uXTrTWEI/kKiYoUW05XhU/GTapDKe1W4CJ 3t9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680792808; x=1683384808; 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=9P6v0ulEd5hUkW/kwOMqiRt3DRCm5f2H5eZvRs3l8jk=; b=y7bJc5e9G/ZGdrRPMsdsUx/Cnv1ONs5W/e5njTcPZOmuX+kGX+EI+XYAlk41s5ENBg q/pHELQ6ICLVwumR4xr7OLQmuB+hisIb95P4T7t7llNOok+KBm20g+K3mRo/wUQkg33M TWwOIml3/tPAkhamF88Jd48NCerZdcrYRb45+Xk6kjbKCBTjWmVyqnpDDMFtnuEC1joZ U55+LHxEOkSglNQeAu8BmFJKHikMbFC34e+38YPbBbDu6E9WFj3k32heG9fZr+ribiO2 TqHGDPFo6EKOZ4RQJcbFMbr33tEM46jqLod/VIjcVUpGIQZId0BSwXt48x/iU5OL3t1E SjQA== X-Gm-Message-State: AAQBX9f8dMiQfGjQ/po1AeQyVkzlCOqffjTBF1lstHFl1fj5TJ39lW7m AfRp3+UYjiO8a4u2AOT/vyk= X-Google-Smtp-Source: AKy350a0ZT6RwZ41KBm+EF0vydWC/nJlB9XBaRGfzy6sQ99HBI2oALceKKSzxUCiY7Iln4XChsWthQ== X-Received: by 2002:a17:90b:3e8b:b0:23a:ad68:25a7 with SMTP id rj11-20020a17090b3e8b00b0023aad6825a7mr11559546pjb.2.1680792808477; Thu, 06 Apr 2023 07:53:28 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id s1-20020a17090ae68100b002349fcf17f8sm3247220pjy.15.2023.04.06.07.53.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Apr 2023 07:53:27 -0700 (PDT) Message-ID: <0af8ab1f-e295-a8ab-6b51-b0fa5e20edc2@gmail.com> Date: Thu, 6 Apr 2023 08:53:26 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] dse: Handle SUBREGs of word REGs differently for WORD_REGISTER_OPERATIONS targets [PR109040] Content-Language: en-US To: Eric Botcazou Cc: Jakub Jelinek , Richard Biener , Richard Sandiford , gcc-patches@gcc.gnu.org References: <612b6215-8bc3-1174-a475-4315176bfe1c@gmail.com> <2876279.e9J7NaK4W3@fomalhaut> From: Jeff Law In-Reply-To: <2876279.e9J7NaK4W3@fomalhaut> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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/6/23 04:15, Eric Botcazou wrote: >> Originally I didn't really see this as an operation. But the more and >> more I ponder it feels like it's an operation and thus should be subject >> to WORD_REGISTER_OPERATIONS. >> >> While it's not really binding on RTL semantics, if we look at how some >> architectures implement reg->reg copies, they're actually implemented >> with an ADD or IOR -- so a real operation under the hood. >> >> If we accept a subreg copy as an operation and thus subject to >> WORD_REGISTER_OPERATIONS then that would seem to imply the combine is >> the real problem here. Otherwise dse is the culprit. > > Yes, I agree that there is an ambiguity for subreg copy operations. At some > point I tried to define what register operations are and added a predicate to > that effect (word_register_operation_p ); while it returns true for SUBREG, > it's an opt-out predicate so this does not mean much. Yea, I saw word_register_operation_p. I was hesitant to treat it as a canonical definition of what ops are and are not subject to WORD_REGISTER_OPERATIONS. > > I don't think that DSE does anything wrong: as I wrote in the PR, defining > WORD_REGISTER_OPERATIONS should not prevent any particular form of RTL. That was the conclusion I'd come to, predicated on treating SUBREGs as affected by WORD_REGISTER_OPERATIONS. > > I therefore think that the problem is in the combiner and probably in the > intermediate step shown by Jakub: > > "Then after that try_combine we do: > 13325 record_value_for_reg (dest, record_dead_insn, > 13326 WORD_REGISTER_OPERATIONS > 13327 && word_register_operation_p (SET_SRC > (setter)) > 13328 && paradoxical_subreg_p (SET_DEST > (setter)) > 13329 ? SET_SRC (setter) > 13330 : gen_lowpart (GET_MODE (dest), > 13331 SET_SRC (setter))); > and the 3 conditions are true here and so record value of the whole setter. > That then records among other things nonzero_bits as 0x8084c." > > That's a recent addition of mine (ae20d760b1ed69f631c3bf9351bf7e5005d52297) > and I think that it probably abuses WORD_REGISTER_OPERATIONS and should either > be reverted or restricted to the load case documented in its comment. I can > provide testing on SPARC if need be. I think that's the job for today. Pan2, Jakub and myself have all zero'd in on this code in combine. jeff