From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) by sourceware.org (Postfix) with ESMTPS id 8570A3858282 for ; Wed, 19 Oct 2022 03:42:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8570A3858282 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-io1-xd29.google.com with SMTP id n73so13444678iod.13 for ; Tue, 18 Oct 2022 20:42:28 -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:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=mdCCZw9Xb1eDIT2UZ8CCaUHf5QDoI1tNrnmM7S/mGho=; b=X7ZndTJMZgP0A7c1rNLKlzIomKVlI4qe8iy72L8opVsf8uKpzLRNmlbaErNysWRJxv 6DHUCFDoLmM+at1pmcu0LpmyQo18olFZyeWNEmw+c4VXSKF0ann5wWBaFl+9ZwWMVJyT nGscs1DlNO0Zgw3aj8PfXOjGmIILCTM3FudAmvSWLnx+HulbtKNMZSH6fPKKd1rP0NVE kPo+QDKgf1Hi5MbpF8Qhs8BiO19C43IDdHlDckq3L8ndR+6ADB/2ZVFCIGwXUvv/L6oV Jre3t797+MUCiDjHMPA8FhhMFj81vop7HL3fYI9i6UOy6Vc/gXxPxTa2XHhNLwIPWbCd pPkA== 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:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mdCCZw9Xb1eDIT2UZ8CCaUHf5QDoI1tNrnmM7S/mGho=; b=nFutq+eZ4WEqJmSPhPQrtKnLWLU1DCc0tEt7/2ImO2QW296mleAELW2JH5My4PN1yW v6Xz7KJ/xoeCYxhCOLYTczWsk6HHFTZzuGWhGOKSRCgwr8tJcur8tA5z7u1UtxGFSz1T gSy/Gr9mvBe8F13Yz1a2/1C9Var77WBA1/iDPzP8vr6NQ62O3SW+EaIgzSA7QvTfE3Xh f0/y4yvFAmxDFGIWHvUTlONesLAPDBsgQP/ep07uXqIcHbghIityVJBYta1NkPbVISpB GO9223+bl7JhMmv7EwBtdvGEQS/jCCzWrlkQFzquL84cX3ooffXV2VgVXp8Bqu92JWtU VttA== X-Gm-Message-State: ACrzQf2fmhV7qRs8YSsvxU1snC41c5q0huJ4o71JQN5Y9scFSIslLMFM 4ii8v5d6JO4oRMFmmyuVyI8= X-Google-Smtp-Source: AMsMyM4RS3l5mGM0MSnzWc4BpCdBWzwLbr2Hx8+OQ7g5VbJWOYUcA32sWjvtzhYOcwdi5KBMPPZUhw== X-Received: by 2002:a02:2711:0:b0:35a:4fb3:efcf with SMTP id g17-20020a022711000000b0035a4fb3efcfmr4705578jaa.14.1666150947606; Tue, 18 Oct 2022 20:42:27 -0700 (PDT) Received: from [172.31.1.18] (65-130-77-9.slkc.qwest.net. [65.130.77.9]) by smtp.gmail.com with ESMTPSA id g14-20020a02850e000000b00363ff12ca47sm1705801jai.125.2022.10.18.20.42.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Oct 2022 20:42:26 -0700 (PDT) Message-ID: <8cbea421-5130-6d37-06a2-42ec7daef5cc@gmail.com> Date: Tue, 18 Oct 2022 21:42:25 -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) To: Vineet Gupta , gcc@gcc.gnu.org Cc: Kito Cheng , Philipp Tomsich References: <1a636f1e-31be-1735-5d8f-649df3c5e018@gmail.com> <1e118c0c-5d9a-4fca-9fe9-12e2baa34019@rivosinc.com> <53dcbef4-7aef-5f63-9bd8-e11c614b0be8@gmail.com> Content-Language: en-US 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.1 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 10/18/22 20:09, Vineet Gupta wrote: > > On 10/18/22 16:36, Jeff Law wrote: >>>> 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. >>> >>> It would have been better (for this specific case) if loop unrolling >>> was not being done so early. The tree pass cunroll is flattening it >>> out and leaving for rest of the all tree/rtl passes to pick up the >>> pieces and remove any redundancies, if at all. It obviously needs to >>> be early if we are injecting 7x more instructions, but seems like a >>> lot to unravel. >> >> Yup.  If that loop gets unrolled, it's going to be a mess.  It will >> almost certainly make this problem worse as each iteration is going >> to have a pair of constants loaded and no good way to remove them. > > Thats the original problem that I started this thread with. I'd > snipped the disassembly as it would have been too much text but > basically on RV, Coremark crc8 loop of const 8 iterations gets > unrolled including extraneous 8 insns pairs to load the same constant > - which is preposterous. Other arches side-step by using if-conversion > / cond moves, latter currently WIP in RV International. x86 w/o > if-convert seems OK since the const can be encoded in the xor insn. > > OTOH given that gimple/tree-pass cunroll is doing the culprit loop > unrolling and introducing redundant const 8 times, can it ne addressed > there somehow. > tree_estimate_loop_size() seems to identify constant expression, not > just an operand. Can it be taught to identify a "non-trivial const" > and hoist/code-move the expression. Sorry just rambling here, most > likely non-sense. Oh, cunroll.  There might be a distinct flag for complete unrolling. I really expect something like Click's work is the way forward. Essentially when you VN the function you'll identify those constants and collapse them all down to a single instance.  Then the GCM phase will kick in and find a place to put the evaluation so that you have one and only one. Some of Bodik's work might catch it as well, though implementing his ideas is likely a lot more work. Jeff