From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by sourceware.org (Postfix) with ESMTPS id 0F4EE3858C83; Fri, 14 Oct 2022 16:54:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0F4EE3858C83 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-x1035.google.com with SMTP id q10-20020a17090a304a00b0020b1d5f6975so5291899pjl.0; Fri, 14 Oct 2022 09:54:29 -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:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=cdVW9965jo1V9iMycxhVPWzA8HszW++5nZCBI/Qhw3s=; b=mZMN0wiuuuKoQTs7v2YkxzHDVdX4WviFFtuA92gSg9RWZuaKjV2YP8TEMX5hdJg70e 7frG039MfukE2S5AEfgwb2D7ULN7Ev/Xwsn3uebdkLUmpGWX2Z2LAtQ+06xzyILiZ3QO SEbQGrQsU3aZLH2t59FwFv+YGbs9RzTOhuKOi18Lde511OBKJhEXqfUDb2CBsccwqMK3 ZwipuQRiwmObxvi1VSYKIZgdaHlI5KPGVnjLZfZsLdPwrYq2wrVMjotAORwQctZ6PIKV 2lRnSOIcGB3wIJDp1cxvYXEQgVb8bqvWnG2DWbeh8LfQy4dr76LqpQwmJaTSYmp9NMMs BdFw== 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: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=cdVW9965jo1V9iMycxhVPWzA8HszW++5nZCBI/Qhw3s=; b=AWiKogYl+VxeHLJXOgzm3IUcsCBoJwubR+muPCIFvPap8YQsTvHsqGsADu5Bve/5Xd U7dJOkX9S5H8CPa1Hmw/fOCxV+/di72GoC1GBx5K5BOnHSf8mPBgMR/ufXtHDv0UDUfT qgRvcw0JDFWW38BZPTH/pU8znYEnOlaZY5imepSoVq6moDxvBZGWBfjj3PaSoPUtWWDb YHXd8NAWY8QyvrAAqFamY8B0Tq6HvniUqs2I6V1rqW8Etf0HckcYK8qZiKwz5UTAPgot Bi6pE/cz0V9+D9M91kMJtAfOPszgpd9lLVYoMCRnUdRJ6DCUXqAVhoE60/MsD40ro4U5 suLw== X-Gm-Message-State: ACrzQf2ktYPXtDz8h8OfJcswic/6E/jrcmwtAFuzeUnpuYzG+HkMFYGg C9gXwin1TmPW06TFZ8rItKA= X-Google-Smtp-Source: AMsMyM5/ECdADfcavNMxAn00wb7EYD6j0G0qv8aRilUL4OnGpM9ta81XfTBBRQAOesvwBZrJwi4arg== X-Received: by 2002:a17:903:40c3:b0:180:cfb7:827b with SMTP id t3-20020a17090340c300b00180cfb7827bmr6285210pld.0.1665766467775; Fri, 14 Oct 2022 09:54:27 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id e37-20020a630f25000000b004608b721dfesm1661032pgl.38.2022.10.14.09.54.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Oct 2022 09:54:27 -0700 (PDT) Message-ID: <1a636f1e-31be-1735-5d8f-649df3c5e018@gmail.com> Date: Fri, 14 Oct 2022 10:54:26 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: Redundant constants in coremark crc8 for RISCV/aarch64 (no-if-conversion) Content-Language: en-US To: Vineet Gupta , gcc@gcc.gnu.org Cc: Christoph Muellner , Philipp Tomsich , Kito Cheng , Jim Wilson References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,BODY_8BITS,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 10/14/22 09:56, Vineet Gupta wrote: > Hi, > > When analyzing coremark build for RISC-V, noticed redundant constants > not being eliminated. While this is a recurrent issue with RV, this > specific instance is not unique to RV as I can trigger similar output > on aarch64 with -fno-if-conversion, hence something which could be > addressed in common passes. > > -O3 -march=rv64gc_zba_zbb_zbc_zbs > > crcu8: >     xor    a3,a0,a1 >     andi    a3,a3,1 >     srli    a4,a0,1 >     srli    a5,a1,1 >     beq    a3,zero,.L2 > >     li    a3,-24576    # 0xFFFF_A000 >     addi    a3,a3,1        # 0xFFFF_A001 >     xor    a5,a5,a3 >     zext.h    a5,a5 > > .L2: >     xor    a4,a4,a5 >     andi    a4,a4,1 >     srli    a3,a0,2 >     srli    a5,a5,1 >     beq    a4,zero,.L3 > >     li    a4,-24576    # 0xFFFF_A000 >     addi    a4,a4,1        # 0xFFFF_A001 >     xor    a5,a5,a4 >     zext.h    a5,a5 > > .L3: >     xor    a3,a3,a5 >     andi    a3,a3,1 >     srli    a4,a0,3 >     srli    a5,a5,1 >     beq    a3,zero,.L4 > >     li    a3,-24576    # 0xFFFF_A000 >     addi    a3,a3,1        # 0xFFFF_A001 > ... > ... > > I see that with small tests cse1 is able to substitute redundant > constant reg with equivalent old reg. I find it easier to reason about this stuff with a graphical CFG, so a bit of ascii art...           2         /    \      3 ---> 4              /    \          5 --->  6 Where BB4 corresponds to .L2 and BB6 corresponds to .L3. Evaluation of the constants occurs in BB3 and BB5. CSE isn't going to catch this.  The best way to think about CSE's capabilities is that it can work on extended basic blocks.     An extended basic block can have jumps out, but not jumps in.  There are 3 EBBs in this code.  (1,2), (4,5) and 6.    So BB4 is in a different EBB than BB3.  So the evaluation in BB3 can't be used by CSE in the EBB containing BB4, BB5. PRE/GCSE is better suited for this scenario, but it has a critical constraint.  In particular our PRE formulation is never allowed to put an evaluation of an expression on a path that didn't have one before.  So while there clearly a redundancy on the path 2->3->4->5 (BB3 and BB5), there is nowhere we could put an evaluation that would reduce the number of evaluation on that path without introducing an evaluation on paths that didn't have one.  So consider 2->4->6.  On that path there are zero evaluations.  So we can't place an eval in BB2 because that will cause evaluations on 2->4->6 which didn't have any evaluations. There isn't a great place in GCC to handle this right now.  If the constraints were relaxed in PRE, then we'd have a chance, but getting the cost model right is going to be tough. Jeff