From patchwork Tue Sep 27 14:46:17 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Hubicka X-Patchwork-Id: 116615 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id AF7B0B6F7E for ; Wed, 28 Sep 2011 00:46:47 +1000 (EST) Received: (qmail 32731 invoked by alias); 27 Sep 2011 14:46:45 -0000 Received: (qmail 32723 invoked by uid 22791); 27 Sep 2011 14:46:44 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Sep 2011 14:46:18 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id C93399AC81D; Tue, 27 Sep 2011 16:46:17 +0200 (CEST) Date: Tue, 27 Sep 2011 16:46:17 +0200 From: Jan Hubicka To: "H.J. Lu" Cc: Jan Hubicka , gcc-patches@gcc.gnu.org, rguenther@suse.de, mjambor@suse.cz Subject: Re: [RFC] Context sensitive inline analysis Message-ID: <20110927144617.GF21364@kam.mff.cuni.cz> References: <20110422123553.GB8655@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org > > This caused: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49179 > > > > > > This also caused: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49091 > Hi, the problem is sign overflow in time computation. Time should be capped by MAX_TIME and we compute MAX_TIME * INLINE_SIZE_SCALE * 2. This happens to be >2^31 & <2^32 so we overflow here because of use of signed arithmetics. Hopefully the following is enough. The floating point arithmetics would make things easier since loop structure can scale times up a lot and their relative comparsions matters for benefit computation. Not sure if switching it to our software floats is the coolest idea however. Will commit it after testing on x86_64-linux Index: ipa-inline-analysis.c =================================================================== --- ipa-inline-analysis.c (revision 179266) +++ ipa-inline-analysis.c (working copy) @@ -92,7 +92,7 @@ along with GCC; see the file COPYING3. /* Estimate runtime of function can easilly run into huge numbers with many nested loops. Be sure we can compute time * INLINE_SIZE_SCALE in integer. For anything larger we use gcov_type. */ -#define MAX_TIME 1000000 +#define MAX_TIME 500000 /* Number of bits in integer, but we really want to be stable across different hosts. */