From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id CA1633858D20 for ; Fri, 23 Jun 2023 10:11:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CA1633858D20 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=none smtp.mailfrom=kam.mff.cuni.cz Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 47BB028AEDD; Fri, 23 Jun 2023 12:11:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1; t=1687515068; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fTdTVhc/OayGsAU9p40xRoLzYW7x1a4AVOX7PMYpL2o=; b=NzQ8iuYjsg+CywokhGnEkhcUGUvmI9VBjD4wRVKU4adaPwuohHCaiu+HMEuUHGyXsp2Q0I EKVnyklFmo+yDmRroX3V6cBIgap2cT6VA89KCQSOBsXs5FadKKbOmYeThji9XTueNLP5c+ LSlIcu/yYjCtYpjyQMNmKueh7VCL/G8= Date: Fri, 23 Jun 2023 12:11:08 +0200 From: Jan Hubicka To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: Re: Do not account __builtin_unreachable guards in inliner Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: > On Mon, Jun 19, 2023 at 12:15 PM Jan Hubicka wrote: > > > > > On Mon, Jun 19, 2023 at 9:52 AM Jan Hubicka via Gcc-patches > > > wrote: > > > > > > > > Hi, > > > > this was suggested earlier somewhere, but I can not find the thread. > > > > C++ has assume attribute that expands int > > > > if (conditional) > > > > __builtin_unreachable () > > > > We do not want to account the conditional in inline heuristics since > > > > we know that it is going to be optimized out. > > > > > > > > Bootstrapped/regtested x86_64-linux, will commit it later today if > > > > thre are no complains. > > > > > > I think we also had the request to not account the condition feeding > > > stmts (if they only feed it and have no side-effects). libstdc++ has > > > complex range comparisons here. Also ... > > > > I was thinking of this: it depends on how smart do we want to get. > > We also have dead conditionals guarding clobbers, predicts and other > > stuff. In general we can use mark phase of cd-dce telling it to ignore > > those statements and then use its resut in the analysis. > > Hmm, possible but a bit heavy-handed. There's simple_dce_from_worklist > which might be a way to do this (of course we cannot use that 1:1). Also > then consider > > a = a + 1; > if (a > 10) > __builtin_unreachable (); > if (a < 5) > __builtin_unreachable (); > > and a has more than one use but both are going away. So indeed a > more global analysis would be needed to get the full benefit. I was looking into simple_dce_from_worklist and if I understand it right, it simply walks list of SSA names which probably lost some uses by the consuming pass. If they have zero non-debug uses and defining statement has no side effects, then they are removed. I think this is not really fitting the bill here since the example above is likely to be common and also if we want one assign filling conditional optimized out, we probably want to handle case with multiple assignments. What about 1) walk function body and see if there are conditionals we know will be optimized out (at the begining those can be only those which has one arm reaching __bulitin_unreachable 2) if there are none, just proceed with fnsummary construction 3) if there were some, do non-cd-dce mark stage which will skip those dead conditional identified in 1 and proceed to fnsummary construction with additional bitmap of marked stmts. This should be cheaper than unconditionally doing cd-dce and should handle common cases? Honza