From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 6D8D23858D32 for ; Tue, 5 Sep 2023 06:53:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6D8D23858D32 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-ej1-x634.google.com with SMTP id a640c23a62f3a-99bdeae1d0aso305765266b.1 for ; Mon, 04 Sep 2023 23:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693896795; x=1694501595; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=pl0kxNt2xDcLrUV3Wdl7UuPaELq/+ZcgIryPpK/rAyI=; b=n0iODdH9jghtuoG37ZmLOZ/lKegISEICwY/fpR7VKD0UBDbKrMT+ilr96hkKZDuurG +Tn1ldLQ/Cs0D8wVkbdeWPxiKNpF/LXSA6F3cqOoALxec7Kiw2pqDaEtUddAKNoH4dOW dkPqFQbPuI+QiZzZWp8gMnzv2+5hQZiWA4OjFKNEajPa3bMnJcQErEsG6NbQ08RukNtY LxXi/jTetYhQ6XPalahoe+/+6VKiLtYj4z6jS229OfM6R11gbtrh0EDulbkWz0k/QFZ+ b7hsu0vMrRMD4vn3Ybc6su3QIfFTTQpzPDnNmw8Y04TikGSVDwVthbqeXI55r4UodZ1z bw6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693896795; x=1694501595; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pl0kxNt2xDcLrUV3Wdl7UuPaELq/+ZcgIryPpK/rAyI=; b=mA0LBMZ+YGzBKpq26hXUcoT/0516BzgyfC/bvBLvg5IXm4yPjbJKrmuNOL+p2rP9Z7 HQVWapIXwvL8iT0WriH+3FI749RUZt93U10mIy/bawpMpinOEU9CfwGDOLW5wSYzfSUy fTuAaRgDeovT6KcwKKB7lB6cF2cfmfQnmW/yNOdlTaDR8qFZ5P8C6k7JyVILoxX2D9JG HwvOAfIRxhaokULXcvXL+DbkN4JG92hXZ2R5o+JFpOSbss+8NpDcZ7pO7iD06gQnH1iS 4Moq9XALzDTQQuPO2ZcbNmx4FSheJuGCHiPTcork7GuR1CB2yN63KXzBJLETsh0nLWpW IjZA== X-Gm-Message-State: AOJu0Yz+dEGGQQ5jv1tNPu3G/faVSe3OuswpVjQZ6S+FVWWudBTey74V lFI3ilKGiJl8cwO9u92j3Cc+2GDu+Ng= X-Google-Smtp-Source: AGHT+IG+J7HtPnTAYcCk5ljoiK1P8qZIv0ucNBtRkVPz0oyOzt1h9S5jKybdi+HPBgvZ0MapoBDG8Q== X-Received: by 2002:a17:906:53cf:b0:9a2:ecd:d95d with SMTP id p15-20020a17090653cf00b009a20ecdd95dmr7919232ejo.68.1693896794873; Mon, 04 Sep 2023 23:53:14 -0700 (PDT) Received: from [192.168.1.23] (ip-046-005-130-086.um12.pools.vodafone-ip.de. [46.5.130.86]) by smtp.gmail.com with ESMTPSA id c11-20020a170906924b00b009929ab17be0sm7144004ejx.162.2023.09.04.23.53.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Sep 2023 23:53:14 -0700 (PDT) Message-ID: <77daf152-e1fe-4980-8297-d37901d925e8@gmail.com> Date: Tue, 5 Sep 2023 08:53:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: rdapp.gcc@gmail.com Subject: Re: [PATCH] fwprop: Allow UNARY_P and check register pressure. To: Jeff Law , gcc-patches , richard.sandiford@arm.com References: <5a90c8a9-1570-5af4-bfdc-19d097bfee6e@gmail.com> <9acc1a24-5d01-40ad-b4b2-5948585d3e8c@gmail.com> <48bed106-190e-ab5f-4099-fdfd4f5a193f@gmail.com> Content-Language: en-US From: Robin Dapp In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 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: > So I don't think I have a good feel for the advantages and disadvantages > of doing this. Robin's analysis of the aarch64 changes was nice and > detailed though. I think the one that worries me most is the addressing > mode one. fwprop is probably the first chance we get to propagate adds > into addresses, and virtual register elimination means that some of > those opportunities won't show up in gimple. > > There again, virtual register elimination wouldn't be the reason for > the ld4_s8.c failure. Perhaps there's something missing in expand. > > Other than that, I think my main question is: why just unary operations? > Is the underlying assumption that we only want to propagate a maximum of > one register? If so, then I think we should check for that directly, by > iterating over subrtxes. The main reason for stopping at unary operations was to limit the scope and change as little as possible (not restricting the change to one register). I'm currently testing a v2 that iterates over subrtxs. > Perhaps we should allow the optimisation without register-pressure > information if (a) the source register and destination register are > in the same pressure class and (b) all uses of the destination are > being replaced. (FWIW, rtl-ssa should make it easier to try to > replace all definitions at once, with an all-or-nothing choice, > if we ever wanted to do that.) I presume you're referring to replacing one register (dest) in all using insns? Source and destination are somewhat overloaded in fwprop context because I'm thinking of the "to be replaced" register as dest when it's actually the replacement register. AFAICT fwprop currently iterates over insns, going through all their uses and trying if an individual use can be substituted. Do you suggest to change this general iteration order to iterate over the defs of an insn and then try to replace all the uses at once (e.g. using ssa->change_insns)? When keeping the current order, wouldn't we need to store all potential changes instead of committing them and later apply them in bulk, e.g. grouped by use? This order would also help to pick the propagation with the most number of uses (i.e. propagation potential) but maybe I'm misunderstanding? Regards Robin