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 0B2503858C39 for ; Fri, 14 Oct 2022 15:57:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0B2503858C39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pj1-x102e.google.com with SMTP id d7-20020a17090a2a4700b0020d268b1f02so8301280pjg.1 for ; Fri, 14 Oct 2022 08:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=subject:cc:to:from:content-language:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=5wKVDBvvzH9JwXk2HyvSqPPehPWVv16s3WNYbN/3PYQ=; b=JGhhaOk3C+rlsGBjEzqD3UcJhe6/DysCPkdVxC+u53WPL4ZZvNLz81m5vZpehYnK/X 1MS0c2GIHId203LkXT/JPD0qhg9RE2JDbbqtonMek4v9QXWb9ToGda+wzR87VBLcmUa1 8EbzV5nnO7OdCsBevO961Ev5VP/c3TFQkhcQlHcj2/dCIyduqJt1ugPeiBc4RUVfS/Ci q8cpPLK5HLoyJ4JWCQjeV3/9QNESmInt/BxMk4d/cS6a4PbgUbnAKS7uA1fldD+DMCq/ qoSWQfNodwBqF/HEJYlbbZS0373PE3J1votx76mCG7Xs2P1N9g2v0jR3pJ0ZcvZWfqn9 wh4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=subject:cc:to:from:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5wKVDBvvzH9JwXk2HyvSqPPehPWVv16s3WNYbN/3PYQ=; b=oA2Fe9GCgR6r3LgXTRE82v5Id/gRzFs53feIx5VPLcMplVkHw4Tov6e1/bsZXjrcLm jSOrNgXCkOlc2SfqimoDkFs6i9pfMMXD51FbFM1u4EqTNsTKZn8Af+hBHTo0//BL0VWN 5Bo+ExK6DP8GJF0s0fedJRRGHmV4n8N1XwsHQAHM2KA9zQFXg8PsINq0viTzAH3rE6fg S6RCtrUuwLIZv+p43uFOPdWlBDbqOKjY3qbm0JSMI6lm3pKwBYCZwbFfHWIvRzA69LlI UdNlJav47dtEuahxO15Fr13c6amwPAnC4mhGqnE7SjptS4X1ALn3R/W86T4860ZjwDut O6LA== X-Gm-Message-State: ACrzQf3v+fyaaZbFFpn+nNtrvcBC7w2OwXNHcSxRJ9GcDVoRJnuvxZJc tvlkkCR0bEMdy1EFDhIn8QPUx8T3puuqM3m+ X-Google-Smtp-Source: AMsMyM6pXtmnCMbsdxM4YeJ3w5s3VmbOZLKJ9GdlTYC6iyqugAKS4E3IG7k2XoRRibHD5o3TuCkXdw== X-Received: by 2002:a17:902:bd47:b0:17f:685b:27ee with SMTP id b7-20020a170902bd4700b0017f685b27eemr5659996plx.22.1665763027346; Fri, 14 Oct 2022 08:57:07 -0700 (PDT) Received: from [192.168.50.116] (c-24-4-73-83.hsd1.ca.comcast.net. [24.4.73.83]) by smtp.gmail.com with ESMTPSA id e10-20020a17090301ca00b00177f4ef7970sm1975004plh.11.2022.10.14.08.57.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Oct 2022 08:57:06 -0700 (PDT) Content-Type: multipart/mixed; boundary="------------D2fNqvVgsr96wZznC1aZGcKq" Message-ID: Date: Fri, 14 Oct 2022 08:56:59 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 X-Mozilla-News-Host: news://news.gmane.io:119 Content-Language: en-US From: Vineet Gupta To: gcc@gcc.gnu.org Cc: Christoph Muellner , Philipp Tomsich , Kito Cheng , Jeff Law , Jim Wilson Subject: Redundant constants in coremark crc8 for RISCV/aarch64 (no-if-conversion) X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is a multi-part message in MIME format. --------------D2fNqvVgsr96wZznC1aZGcKq Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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. cse_insn make_regs_equiv() .. canon_reg() e.g. void foo(void) { bar(2072, 2096); } foo: li a0,4096 addi a1,a0,-2000 addi a0,a0,-2024 tail bar And it seems to even work across basic blocks. e.g. void foo(int x) # -O2 { bar1(2072); foo2(); if (x) bar2(2096); } foo: ... li s1, 4096 addi a0, s1, -2024 ... addi a0, a1, -2000 tail bar2 It seems cse redundancy elimination logic is scoped to "paths" created by cse_find_path() and those seems to chain only 2 basic blocks. ;; Following path with 17 sets: 2 3 ;; Following path with 15 sets: 4 5 ;; Following path with 15 sets: 6 7 ;; Following path with 15 sets: 8 9 ;; Following path with 15 sets: 10 11 ;; Following path with 15 sets: 12 13 ;; Following path with 15 sets: 14 15 ;; Following path with 13 sets: 16 17 ;; Following path with 2 sets: 18 ... While in this case the BBs containing the dups are 6, 8, ... (note 36 35 37 6 [bb 6] NOTE_INSN_BASIC_BLOCK) (insn 37 36 38 6 (set (reg:DI 196) (const_int -24576 [0xffffffffffffa000])) "../../coremark-crc8.c":23:17 -1 (nil)) ... (note 54 53 55 8 [bb 8] NOTE_INSN_BASIC_BLOCK) (insn 55 54 56 8 (set (reg:DI 207) (const_int -24576 [0xffffffffffffa000])) "../../coremark-crc8.c":23:17 -1 (nil)) The path construction logic in cse seems non trivial for someone just starting to dig into that code so I'd appreciate some insight. Also I'm wondering if cse is the right place to do this at all, or should it be done in gcse/PRE ? TIA -Vineet P.S. With the proposed RV cond ops extension if-conversion could elide this specific instance of problem, however redundant constants are a common enough nuisance in RV codegen whcih we need to tackle, specially when it is typically a 2 instruction seq. --------------D2fNqvVgsr96wZznC1aZGcKq Content-Type: text/x-csrc; charset=UTF-8; name="coremark-crc8.c" Content-Disposition: attachment; filename="coremark-crc8.c" Content-Transfer-Encoding: base64 dHlwZWRlZiB1bnNpZ25lZCBzaG9ydCBlZV91MTY7CnR5cGVkZWYgdW5zaWduZWQgY2hhciBl ZV91ODsKCmVlX3UxNgpjcmN1OChlZV91OCBkYXRhLCBlZV91MTYgY3JjKQp7CiAgICBlZV91 OCBpID0gMCwgeDE2ID0gMCwgY2FycnkgPSAwOwoKICAgIGZvciAoaSA9IDA7IGkgPCA4OyBp KyspCiAgICB7CiAgICAgICAgeDE2ID0gKGVlX3U4KSgoZGF0YSAmIDEpIF4gKChlZV91OClj cmMgJiAxKSk7CiAgICAgICAgZGF0YSA+Pj0gMTsKCiAgICAgICAgaWYgKHgxNiA9PSAxKQog ICAgICAgIHsKICAgICAgICAgICAgY3JjIF49IDB4NDAwMjsKICAgICAgICAgICAgY2Fycnkg PSAxOwogICAgICAgIH0KICAgICAgICBlbHNlCiAgICAgICAgICAgIGNhcnJ5ID0gMDsKICAg ICAgICBjcmMgPj49IDE7CiAgICAgICAgaWYgKGNhcnJ5KQogICAgICAgICAgICBjcmMgfD0g MHg4MDAwOwkvLyBzZXQgTVNCIGJpdAogICAgICAgIGVsc2UKICAgICAgICAgICAgY3JjICY9 IDB4N2ZmZjsJLy8gY2xlYXIgTVNCIGJpdAogICAgfQogICAgcmV0dXJuIGNyYzsKfQo= --------------D2fNqvVgsr96wZznC1aZGcKq--