From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) by sourceware.org (Postfix) with ESMTPS id 23BF5385840D for ; Wed, 9 Mar 2022 07:36:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 23BF5385840D Received: by mail-qk1-x72e.google.com with SMTP id h196so1060688qke.12 for ; Tue, 08 Mar 2022 23:36:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pBdY64B8AkowRM02qu1PmIB6ytrjuagYhJ6LQafitlo=; b=u1XubMr4rPH0qH9yBQCu6oqQrnX9hzn0l1WWsf8rL+C6Xf8xJl/daHYfRPK819b9cL ZWWf4QA/8zunA58yrt+O/CifEEperRr0prLDuV1RyWbp8TLVWXsEbWPYyJwqq5sy+0hP 784nXp7Gw9n5vc/gv315qHQaJN6y6euVESh0Vvzq9yvWimV63m7xl506NIYXPe9aqu55 mg5spa7heyOgy4S/xuXEY/Okb7+MoeZDS1oBc6ZEgoSdwMg+Eu59urxcR0cxSKwp3SRb CZREuRQLpf44ZXfOyO9wGcXhj9IAivRVXGrcAc4vX81jxTtQ0PDTfUDY3B0AbkyN3xbq YMKw== X-Gm-Message-State: AOAM533wyvH9wfXCm9LZ6jZoAf3JMBs+IvYbogZB4nc2LgmqWK45/6LF NJGI8BVT67/ImS/JgaSx5okgrbNFiIO5AD/Yf72RdlT8/OE= X-Google-Smtp-Source: ABdhPJxxraR5ADI4PMYNRRUtMyoniOXbe4vMqsJrxbEC2W6k/3xKvmaoq/INtgN8NAPIUdOV52/XST4/yPWqBQW3nRY= X-Received: by 2002:a05:620a:2586:b0:67b:1141:ce24 with SMTP id x6-20020a05620a258600b0067b1141ce24mr11207345qko.542.1646811390591; Tue, 08 Mar 2022 23:36:30 -0800 (PST) MIME-Version: 1.0 References: <027501d83211$eb989d70$c2c9d850$@nextmovesoftware.com> <001401d83219$bc707f10$35517d30$@nextmovesoftware.com> In-Reply-To: <001401d83219$bc707f10$35517d30$@nextmovesoftware.com> From: Uros Bizjak Date: Wed, 9 Mar 2022 08:36:19 +0100 Message-ID: Subject: Re: [x86 PATCH] PR tree-optimization/98335: New peephole2 xorl;movb -> movzbl To: Roger Sayle Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2022 07:36:32 -0000 On Mon, Mar 7, 2022 at 12:51 PM Roger Sayle wr= ote: > > > Hi Uros, > > > Is there a reason that only inserts to DImode registers are implemented= ? > > IMO, these peepholes should also handle inserts to SImode. > > I wasn't able to construct a test case that produced a byte or word inser= t > into an SImode register. The front-ends and middle-end end up producing > different code sequences, and -m32 changes the ABI so that small structs > get passed in memory rather than in registers. > > Here's the expanded testcase that I investigated: > > struct DataCL { char a; int b; }; > struct DataWL { short a; int b; }; > struct DataIL { int a; int b; }; > > struct DataCI { char a; short b; }; > struct DataWI { short a; short b; }; > > char c; > short w; > int i; > > DataCL foo_cl(int idx) { return { c }; } > DataCL bar_cl(int idx) { return { c, 0 }; } > DataWL foo_wl(int idx) { return { w }; } > DataWL bar_wl(int idx) { return { w, 0 }; } > DataIL foo_il(int idx) { return { i }; } > DataIL bar_il(int idx) { return { i, 0 }; } > > DataCI foo_ci(int idx) { return { c }; } > DataCI bar_ci(int idx) { return { c, 0 }; } > DataWI foo_wi(int idx) { return { w }; } > DataWI bar_wi(int idx) { return { w, 0 }; } > > > I agree that for completeness similar peepholes handling inserts into > SImode would be a good thing, but these wouldn't be restricted by > TARGET_64BIT and would therefore require additional -m32 testing. > The DImode peepholes I can justify for stage4 as PR tree-opt/98335 > is a regression, SImode peepholes would be more of a "leap of faith". > If you=E2=80=99d be willing to accept a patch without a testcase, let me = know. We have plenty of these, where we assume that if the pattern works in one mode, it also works in other modes. So, I think that by changing DI mode to SWI48 mode iterator, we are on the safe side. We can also trust bootstrap and regression tests here. IMO, the patch with SWI48 mode iterator is OK. Thanks, Uros. > > It's also a pity that subreg handling in combine doesn't allow merging > these inserts into zero registers to be combined to zero_extends in a > machine independent way. My recent patch for PR 95126 (awaiting > review) should also allow front-ends and middle-end passes more > flexibility in optimizing small struct constructors. > > Thanks (as always) for reviewing patches so quickly. > > Roger > -- > >