From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52124 invoked by alias); 20 Dec 2019 11:13:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 52116 invoked by uid 89); 20 Dec 2019 11:13:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1788, knob X-HELO: mail-wm1-f41.google.com Received: from mail-wm1-f41.google.com (HELO mail-wm1-f41.google.com) (209.85.128.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Dec 2019 11:13:49 +0000 Received: by mail-wm1-f41.google.com with SMTP id t14so8795775wmi.5 for ; Fri, 20 Dec 2019 03:13:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=3RCFWsbudZ9Jh6uL/UvbwPsktadA7JHnDs+smTnA5wc=; b=lRb5B2K78mXKkfqzA3LEqLL73OKv7Nexb882YCiGshRwryFDmAbnj1ms7JZ5Oi4yz2 AfCg5TIRIA2eNzWJF4YX7p9ycEomCZ2FuesuU1Ewy7dpskRn/ZA3wGRRGY89Wo12ChFo V3LMcaIM7F7xEZZ82I1RH0ynD9BZcnHBSSHll2XYL11ZuaRwGECJG1chyvt2GHuAx8sa 45J5S0utqUvbWuoQg2SdEpenY3TnEzmPV5fpXsuYceK+XC9xZMl4LdTk/cXz633RRPZJ SfXi/HyoDL/PKzqyTEN+BK37aFLx44VFXfZbB8zhldDVn5YSAYc7Jm0s+S7xsinvGigL qr5A== Return-Path: Received: from [192.168.178.32] (x5f731ceb.dyn.telefonica.de. [95.115.28.235]) by smtp.gmail.com with ESMTPSA id m7sm9352631wrr.40.2019.12.20.03.13.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Dec 2019 03:13:46 -0800 (PST) Date: Fri, 20 Dec 2019 11:13:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: References: <9A7132EC-5B85-4AF1-A6B9-7DAB0FA11759@ORACLE.COM> <4BDA1047-B75A-49EE-8DBE-0B1C0F646205@ORACLE.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Does gcc automatically lower optimization level for very large routines? To: law@redhat.com,Jeff Law ,Qing Zhao ,Dmitry Mikushin CC: GCC From: Richard Biener Message-ID: X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00362.txt.bz2 On December 20, 2019 1:41:19 AM GMT+01:00, Jeff Law wrote: >On Thu, 2019-12-19 at 17:06 -0600, Qing Zhao wrote: >> Hi, Dmitry, >>=20 >> Thanks for the responds.=20 >>=20 >> Yes, routine size only cannot determine the complexity of the >routine. Different compiler analysis might have different formula with >multiple parameters to compute its complexity.=20 >>=20 >> However, the common issue is: when the complexity of a specific >routine for a specific compiler analysis exceeds a threshold, the >compiler might consume all the available memory and abort the >compilation.=20 >>=20 >> Therefore, in order to avoid the failed compilation due to out of >memory, some compilers might set a threshold for the complexity of a >specific compiler analysis (for example, the more aggressive data flow >analysis), when the threshold is met, the specific aggressive analysis >will be turned off for this specific routine. Or the optimization level >will be lowered for the specific routine (and given a warning during >compilation time for such adjustment).=20=20 >>=20 >> I am wondering whether GCC has such capability? Or any option >provided to increase or decrease the threshold for some of the common >analysis (for example, data flow)? >>=20 >There are various places where if we hit a limit, then we throttle >optimization. But it's not done consistently or pervasively. > >Those limits are typically around things like CFG complexity. Note we also have (not consistently used) -Wmissed-optimizations which is s= upposed to warn when we run into this kind of limiting telling the user whi= ch knob he might be able to tune.=20 Richard.=20 >We do _not_ try to recover after an out of memory error, or anything >like that. > >jeff >>=20