From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id E946F3858D1E for ; Thu, 7 Sep 2023 14:25:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E946F3858D1E 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-x632.google.com with SMTP id a640c23a62f3a-99c3c8adb27so124118266b.1 for ; Thu, 07 Sep 2023 07:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694096746; x=1694701546; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=uVbYDPIm9Q9oVeUqCsk/oVLFJfs9OnZknGn7pwnsMrk=; b=mRo8SAOzAggr2J9TjJJ/2ySTn3n4TmPiWXOyd0PEhOw/LefEpNgWzlVwvSDEmEK1Kg 7EbSoq/ldMnFwtZIGq1F9c5NSkkVzHZImCT3JF4e9g5wVaodScMhXzRn6Hz5UD1pnnU+ s0wwQF+j3offvWQ3yGdsIMtiqJLvAS32IbiZQ4GDnHDYxldsORykyOyb/CVS+ZifbU/I Hqx89Bpx5CeKmNbaxuf9N8siO1sWXTTkbFmsiX1+R4BkAic2hXyISOENfatNA3Kysyia 7f0GwMNzq75wi3TUrN4O/plhN3Zfi0QUEoKCfcc+2i+tgjhUkn5u+IHi2JtzLmiFjVoh tuVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694096746; x=1694701546; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uVbYDPIm9Q9oVeUqCsk/oVLFJfs9OnZknGn7pwnsMrk=; b=T1QdKbUfPDWiloB6nsO0VH1qunJ4E8s0v4rd7rmhnF6Fgjxexf+NyKArgOn4pT7sqc qoI0tc+rbYBhBNMFrg+eOG6YcA9pfJWMe++tOiDYvQtrDjifnViYtSg23T9Z2WAAbaQw xsK7NqxOFwMwEUOVwmNhv2cmStnkhTLBzP8nlKeJplztkkHwpke1jLFWiHAu2s0w7sCB vfuOXT1vYXckUTOKiS5p+7DBjIEqk/Px6NUMlzJFHjVCP86wQiiXp1TyPa8mLerOrnEu tIa15ppw/E5zhMDFrbH43sb0qjqayj0YZwNo5txi+Dnt8Isua3eAzCRdnretBPi+3w3I KyXA== X-Gm-Message-State: AOJu0YxRKXAU00PluoQsIDlk1Guh66U3Gs3oDnOBn6qdTD2mhyhvhCLY 4hHscxH0rC2IPxsbpIiFvJg= X-Google-Smtp-Source: AGHT+IFoWQveo84tuFPzlztiD+splhm4aSTRZI5lE+QKYBKEYkZ6rQ0s+qwb5fEe/8xCTWQXYqFv0w== X-Received: by 2002:a17:907:d690:b0:9a9:f042:dec0 with SMTP id wf16-20020a170907d69000b009a9f042dec0mr536001ejc.38.1694096746385; Thu, 07 Sep 2023 07:25:46 -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 kg12-20020a17090776ec00b0099364d9f0e6sm10526660ejc.117.2023.09.07.07.25.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Sep 2023 07:25:46 -0700 (PDT) Message-ID: <3f2b6571-4c47-3ea5-2932-4060e45a94ea@gmail.com> Date: Thu, 7 Sep 2023 16:25:45 +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. Content-Language: en-US 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> <77daf152-e1fe-4980-8297-d37901d925e8@gmail.com> 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: Thanks for looking at it in detail. > Yeah, I think this is potentially a blocker for propagating A into B > when A is used elsewhere. Combine is able to combine A and B while > keeping A in parallel with the result. I think either fwprop would > need to try that too, or it would need to be restricted to cases where A > is only used in B. That seems a rather severe limitation and my original use case would not get optimized considerably anymore. The intention was to replace all uses (if register pressure allows). Of course the example is simple enough that a propagation is always useful if the costs allow it, so it might not be representative. I'm wondering if we could (my original misunderstanding) tentatively try to propagate into all uses of a definition and, when reaching a certain ratio, decide that it might be worth it, otherwise revert. Would be very crude though, and not driven by the actual problem we're trying to avoid. > I think the summary is: > > IMO, we have to be mindful that combine is still to run. We need to > avoid making equal-cost changes if the new form is more complex, or > otherwise likely to interfere with combine. I guess we don't have a good measure for complexity or "combinability" and even lower-cost changes could result in worse options later. Would it make sense to have a strict less-than cost policy for those more complex propagations? Or do you consider the approach in its current shape "hopeless", given the complications we discussed? > Alternatively, we could delay the optimisation until after combine > and have freer rein, since we're then just mopping up opportunities > that other passes left behind. > > A while back I was experimenting with a second combine pass. That was > the original motiviation for rtl-ssa. I never got chance to finish it > off though. This doesn't sound like something that would still materialize before the end of stage 1 :) Do you see any way of restricting the current approach to make it less intrusive and still worthwhile? Limiting to vec_duplicate might be much too arbitrary but would still help for my original example. Regards Robin