From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by sourceware.org (Postfix) with ESMTPS id 55EFA381DC40 for ; Fri, 16 Sep 2022 01:32:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 55EFA381DC40 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-x102e.google.com with SMTP id x1-20020a17090ab00100b001fda21bbc90so24114387pjq.3 for ; Thu, 15 Sep 2022 18:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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; bh=NczSSTB5oGq36M25a3f/f4Buylrxo2v4LeV6LCW9hQw=; b=FMUImXtPVaYpHtrNrBsv4f8BIN/7uHwCXDAwWwNV9cx7dk6UfuitSSHqhhj6XNOrRy y5F4yKPuAnP1nZSux+HpvMGGXeNH7C3jGi3uBsaY6IpwexV4cg81LDXI1qr7du/dT/sS lxAAmM7bi7KSYdkdbi4mtGsbXDBYtNDXl1p7ZbAJ4fgex/rHDiW4vHrINX7c21t34Nfr U1RPL5YHiHv9IAJj05BFVs/3qypD9Xp1pKsQwt0V+yfRFrlvMywIWWiR/jYnFyrXqDCQ 9njsPRxBQuq2jIKuhbOBYnP8NCiadrBUfKKIK0onth7/kLonpbVdccBOrXmqA2g5QQ4c q6hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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; bh=NczSSTB5oGq36M25a3f/f4Buylrxo2v4LeV6LCW9hQw=; b=s3leVmUY+QvVbVe1h2L/9z/3pMVKOhoDthayOdZBJbCD3CK9Jze8ifGcbk/oVBDZzD 9M6mYDY21OyOxzHqLyUND2uGQHWkzLHzvl3ajxZL4Lyl+8n2oEEA8bHYRP9HKS34Av8+ bR+J4fOmwb5UvftrkD0yTb5CwOBlr+OpUTUdgSLen8640FH/H1hrdzhd+1vkbCZP52gJ jVfKkw0c+MKpvuBC1EQ0hm4kTSDWQsxWtE6M4nsKxT4BJEAh/cAkBMv8v70SV7+K7t5f 3mqHypSSHtosDnNkGi4G/h3ytN1flgMWkZLiIp8OIQ7qzk0dcCk89ksbcf3ikFod93ll 7zsQ== X-Gm-Message-State: ACrzQf3iDdbSy+6PZzor9VD/FXpQNsJPyXzGTlBAYNwDHVuDtpJfUapD gV+K/ZvKsS141jzpUnK7ku/N6gUPcQ0erg== X-Google-Smtp-Source: AMsMyM79fS9u1vxElgZxPiXNz53Stux76zlKTYpCAbsWFxH8bfKmYjDCaK3ltkYpYGhwjOfIphzhOQ== X-Received: by 2002:a17:903:1c1:b0:178:1c92:e35 with SMTP id e1-20020a17090301c100b001781c920e35mr2254558plh.151.1663291918683; Thu, 15 Sep 2022 18:31:58 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id l4-20020a17090b078400b002002f9eb8c4sm282662pjz.12.2022.09.15.18.31.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Sep 2022 18:31:58 -0700 (PDT) Message-ID: <261569e3-d4e9-5b64-b97d-8120b49b92a9@gmail.com> Date: Thu, 15 Sep 2022 19:31:56 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [PATCH] [x86]Don't optimize cmp mem, 0 to load mem, reg + test reg, reg Content-Language: en-US To: gcc-patches@gcc.gnu.org References: <20220916010659.37555-1-hongtao.liu@intel.com> From: Jeff Law In-Reply-To: <20220916010659.37555-1-hongtao.liu@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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 9/15/22 19:06, liuhongt via Gcc-patches wrote: > There's peephole2 submit in 1990s which split cmp mem, 0 to load mem, > reg + test reg, reg. I don't know exact reason why gcc do this. > > For latest x86 processors, ciscization should help processor frontend > also codesize, for processor backend, they should be the same(has same > uops). > > So the patch deleted the peephole2, and also modify another splitter to > generate more cmp mem, 0 for 32-bit target. > > It will help instruction fetch. > > for minmax-1.c minmax-2.c minmax-10, pr96891.c, it's supposed to scan there's no > comparison to 1 or -1, so adjust the testcase since under 32-bit > target, we now generate cmp mem, 0 instead of load + test. > > Similar for pr78035.c. > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,} > No performance impact for SPEC2017 on ICX/Znver3. > > Ok for trunk? > > gcc/ChangeLog: > > * config/i386/i386.md (*3_1): Replace > register_operand with nonimmediate_operand for operand 1. Also > force_reg it when mode is QImode. > (define_peephole2): Deleted related peephole2. > > gcc/testsuite/ChangeLog: > > * gcc.target/i386/minmax-1.c: Scan-assemble-not for cmp with 1 > or -1, also don't scan-assembler test for ia32. > * gcc.target/i386/minmax-10.c: Ditto. > * gcc.target/i386/minmax-2.c: Ditto. > * gcc.target/i386/pr78035.c: Ditto. > * gcc.target/i386/pr96861.c: Scan either cmp or test 3 times. It was almost certainly for PPro/P2 given it was rth's work from 1999.    Probably should have been conditionalized on PPro/P2 at the time.   No worries losing it now... Jeff