From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29459 invoked by alias); 11 Nov 2008 20:11:24 -0000 Received: (qmail 18995 invoked by uid 48); 11 Nov 2008 20:09:55 -0000 Date: Tue, 11 Nov 2008 20:11:00 -0000 Message-ID: <20081111200955.18993.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "hubicka at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-11/txt/msg00824.txt.bz2 ------- Comment #7 from hubicka at gcc dot gnu dot org 2008-11-11 20:09 ------- Current implementation of inliner is perfectly unaware of the debug info size implications. There is alternative to limit number of BLOCKS in function body growth same way as we limit stack usage that would just add little extra bookkeeping, but I would like to be sure that there is no better alternative first. Current BLOCK removal code is quite conservative based on my observations of what RTL code did originally, perhaps we can be more strict? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37709