From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by sourceware.org (Postfix) with ESMTPS id 4088D3858D20 for ; Wed, 5 Apr 2023 17:31:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4088D3858D20 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-x1029.google.com with SMTP id gp15-20020a17090adf0f00b0023d1bbd9f9eso40276135pjb.0 for ; Wed, 05 Apr 2023 10:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680715869; x=1683307869; 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=bHVE+gSAdGgzr8G4G+2h/5UYeTPvwbJBG8wkjNc/5e8=; b=I+HsIvXNkZ1O3gOEqZwva+/AFM9fDQVicShYkppYzdpXA3aaGXQXvHIi2A2iX2+arr EsVkB9gYl/HQzVcRr6c1QE7CqIMpOURw8Kx+1wYDCabr/I4W9XxgdChEqXCT62Py2UUs FdbDfelzEPvy56tX1OAX+9MMeFTYx4QtU4WpL1f69WyJzqJiEqxRToyh9wa34EnDyUlY lIqItvHrgm7RAqS47McGjhAhB2vbB2ZaO1TALy+Dwem6lUHiSAoGUb6ZEFFlHu+s6Qi5 PV88WQ1MCHG7+dgpgZwTvXiOgSHlVvTPpgC2I97cBxaII6e8EOTvvSL67rezB4r6fmSh FK9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680715869; x=1683307869; 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=bHVE+gSAdGgzr8G4G+2h/5UYeTPvwbJBG8wkjNc/5e8=; b=O3CNK+TZU/Kw0i4VPMRe6VMeuipktLYMwbBFTTXBjlqcdB/qT6sih+ITPGVGW2ggDp WOCU0GC4IHGqjQJeH6VkcLiP9vp+e+fxDuZaUOUqEaDWY+qD+3fKNJ6vg1M1yYGQLn92 i9H4I1NpvsUW0T455bXYngRvS6zguISF8WjMEcH687B5uN2Y2Bu4Id/7M1IwEYH3p6wF jhf1NZ/HNIQqxd14t9E22tD58/R0oK1CL9Id5om0Mc6YFmYAJ4mmxgzdC0grR1HxtTJC kRorTi2nSJHDfvMfqb6HBo/8ZluGc0aDjQ/yr0Lfi8NX8ttqq8U8yhmpoAsmr7zBKo0N 96Aw== X-Gm-Message-State: AAQBX9fYqCE5RYoqGk6aMglv8iC1vjniDTCm608Sd+QQCfDzvADsCG0Y U+B4bARAW2tqhh+FC5/Hk4c= X-Google-Smtp-Source: AKy350bDgGy5PKRsXw4Rl2SbUL3S4SCO9C7Y06ptrywn0KXbCgMyrt3IsqgjmIuqRz0WV8uCHQN9/w== X-Received: by 2002:a17:902:dad0:b0:1a1:da3c:605f with SMTP id q16-20020a170902dad000b001a1da3c605fmr8082630plx.58.1680715868938; Wed, 05 Apr 2023 10:31:08 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id 67-20020a630646000000b005136181264fsm9619176pgg.34.2023.04.05.10.31.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Apr 2023 10:31:08 -0700 (PDT) Message-ID: <612b6215-8bc3-1174-a475-4315176bfe1c@gmail.com> Date: Wed, 5 Apr 2023 11:31:07 -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: Jakub Jelinek Cc: Richard Biener , Richard Sandiford , Eric Botcazou , gcc-patches@gcc.gnu.org References: <8e0e3cd5-e4db-ce8a-b7dc-baac32aed516@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.0 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/5/23 10:48, Jakub Jelinek wrote: > On Wed, Apr 05, 2023 at 10:17:59AM -0600, Jeff Law wrote: >>> It is true that an instruction like >>> (insn 8 7 9 2 (set (reg:HI 141) >>> (subreg:HI (reg:SI 142) 0)) "aauu.c":6:18 181 {*movhi_internal} >>> (nil)) >>> can appear in the IL on WORD_REGISTER_OPERATIONS target, but I think the >>> upper bits shouldn't be random garbage in that case, it should be zero >>> extended or sign extended. >> Well, that's one of the core questions here. What are the state of the >> upper 16 bits of (reg:HI 141)? The WORD_REGISTER_OPERATIONS docs aren't >> 100% clear as we're not really doing any operation. >> >> So again, I think we need to decide if the DSE transformation is correct or >> not. I *think* we can aggree that insn 39 is OK. It's really the semantics >> of insn 47 that I think we need to agree on. What is the state of the upper >> 16 bits of (reg:HI 175) after insn 47? > > I'm afraid I don't know the answers here, I think Eric is > WORD_REGISTER_OPERATIONS expert here I think these days (most of the major > targets are !WORD_REGISTER_OPERATIONS). Hopefully he'll chime in. > Intuitively, WORD_REGISTER_OPERATIONS from the description would be > that > (insn 47 35 39 2 (set (reg:HI 175) > (subreg:HI (reg:SI 166) 0)) "pr109040.c":9:11 179 {*movhi_internal} > (expr_list:REG_DEAD (reg:SI 166) > (nil))) > would copy not just the low 16-bits of pseudo 166 to 175, but also the upper > 16-bits. I've gone back and forth repeatedly on this. 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. But if that is so, then something is broken in the code below. > Some archeology shows that we were doing that on all arches initially > and then > Wed May 13 17:38:35 1998 Richard Kenner > > * combine.c (simplify_comparison, case AND): Don't commute AND > with SUBREG if constant is whole mode and don't do if lowpart > and not WORD_REGISTER_OPERATIONS. > restricted that to WORD_REGISTER_OPERATIONS only. > The whole optimization is then likely > Wed Mar 18 05:54:25 1998 Richard Kenner > > * combine.c (gen_binary): Don't make AND that does nothing. > (simplify_comparison, case AND): Commute AND and SUBREG. > * i386.h (CONST_CONSTS, case CONST_INT): One-byte integers are cost 0. > but the code has been tweaked further many times since then. Sigh. 1998 and probably directly from Kenner's tree at the time. So no public discussion, likely no testcases either. Off to my private archives. Yup, no discussion of Kenner's patch or testcase. Interestingly enough I did stumble across Andreas Schwab reporting a bug in Kenner's change, though on the m68k and unrelated to WORD_REGISTER_OPERATIONS jeff