From patchwork Fri Nov 29 14:33:12 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 295418 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 96CE12C00AA for ; Sat, 30 Nov 2013 01:33:36 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; q=dns; s=default; b=MIRWjG7i8L7bNDD4jw L34kPTNrGCy7Y7c4/tso1Zhw2btUHIR2VqF/181GFhUCuYNRYS6lF327i7oRw7/9 M3DyljYytAe0Tv5vd+yXALHI9pcYoPu4TKazViRgkrxSCt/PpzNtpdVFY3wfjYkL oSfTGG9zyg2eW3rm7DKNK1J4s= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; s=default; bh=q2Jmt6Dgl5iJTy7GOuugqaHq +YE=; b=r1nGmxDhGezAbh/fZh1/s07LGOmiJ3NlHOU8STu0w7iz4bpT7pr3GsJQ Xcx/6CfvgrJ3ONXg9DtULFeAXk5S1ThH19/OcRjQ3rsH9iKHAO+mvEvoVQHjH+fr i3wuKqpx3bExp2wAij53VhNbNuV0go4KGJgGz8MVWe7Uk3ApCz4= Received: (qmail 19273 invoked by alias); 29 Nov 2013 14:33:23 -0000 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 Received: (qmail 19264 invoked by uid 89); 29 Nov 2013 14:33:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.2 required=5.0 tests=AWL, BAYES_99, FREEMAIL_FROM, RDNS_NONE, SPF_PASS, URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mail-we0-f181.google.com Received: from Unknown (HELO mail-we0-f181.google.com) (74.125.82.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 29 Nov 2013 14:33:21 +0000 Received: by mail-we0-f181.google.com with SMTP id x55so9333327wes.40 for ; Fri, 29 Nov 2013 06:33:12 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.210.134 with SMTP id mu6mr7081391wic.37.1385735592352; Fri, 29 Nov 2013 06:33:12 -0800 (PST) Received: by 10.195.12.114 with HTTP; Fri, 29 Nov 2013 06:33:12 -0800 (PST) In-Reply-To: References: <20131128172255.GA12738@intel.com> Date: Fri, 29 Nov 2013 15:33:12 +0100 Message-ID: Subject: Re: RFC: PR bootstrap/59199: [4.9 Regression] r205032 caused LTO bootstrap to fail with bootstrap-profile From: Richard Biener To: "H.J. Lu" , Jan Hubicka Cc: GCC Patches X-IsSubscribed: yes On Fri, Nov 29, 2013 at 1:47 PM, Richard Biener wrote: > On Fri, Nov 29, 2013 at 1:27 PM, H.J. Lu wrote: >> On Fri, Nov 29, 2013 at 2:26 AM, Richard Biener >> wrote: >>> On Thu, Nov 28, 2013 at 6:22 PM, H.J. Lu wrote: >>>> There is a bad interaction between inlined C++ member functions >>>> and LTO + profiledbootstrap, which leads to >>>> >>>> LTO bootstrap to fail with bootstrap-profile: >>>> >>>> Existing SSA name for symbol marked for renaming: aloop_37 >>>> In member function \u2018__base_ctor \u2019: >>>> lto1: internal compiler error: SSA corruption >>>> 0xcd84eb update_ssa(unsigned int) >>>> /export/project/git/gcc-regression/gcc/gcc/tree-into-ssa.c:3246 >>>> 0xa5814c input_function >>>> /export/project/git/gcc-regression/gcc/gcc/lto-streamer-in.c:1006 >>>> 0xa5814c lto_read_body >>>> /export/project/git/gcc-regression/gcc/gcc/lto-streamer-in.c:1070 >>>> 0xa5814c lto_input_function_body(lto_file_decl_data*, cgraph_node*, char >>>> const*) >>>> /export/project/git/gcc-regression/gcc/gcc/lto-streamer-in.c:1112 >>>> 0x66d2bc cgraph_get_body(cgraph_node*) >>>> /export/project/git/gcc-regression/gcc/gcc/cgraph.c:2981 >>>> 0x99aa58 ipa_merge_profiles(cgraph_node*, cgraph_node*) >>>> /export/project/git/gcc-regression/gcc/gcc/ipa-utils.c:699 >>>> 0x595a86 lto_cgraph_replace_node >>>> /export/project/git/gcc-regression/gcc/gcc/lto/lto-symtab.c:82 >>>> 0x596159 lto_symtab_merge_symbols_1 >>>> /export/project/git/gcc-regression/gcc/gcc/lto/lto-symtab.c:561 >>>> 0x596159 lto_symtab_merge_symbols() >>>> /export/project/git/gcc-regression/gcc/gcc/lto/lto-symtab.c:589 >>>> 0x5850dd read_cgraph_and_symbols >>>> /export/project/git/gcc-regression/gcc/gcc/lto/lto.c:2946 >>>> 0x5850dd lto_main() >>>> /export/project/git/gcc-regression/gcc/gcc/lto/lto.c:3255 >>>> Please submit a full bug report, >>>> with preprocessed source if appropriate. >>>> Please include the complete backtrace with any bug report. >>>> See for instructions. >>>> >>>> There are only 2 files which don't inline all loop_iterator >>>> member function and may be miscompiled: >>>> >>>> File: ipa-inline-analysis.o >>>> >>>> Symbol table '.symtab' contains 454 entries: >>>> Num: Value Size Type Bind Vis Ndx Name >>>> ... >>>> 262: 0000000000000000 0 NOTYPE LOCAL DEFAULT 5 >>>> loop_iterator::loop_iterator(loop**, unsigned int) >>>> ... >>>> 352: 0000000000000000 89 FUNC WEAK DEFAULT 27 >>>> loop_iterator::next() >>>> 353: 0000000000000000 748 FUNC WEAK DEFAULT 30 >>>> loop_iterator::loop_iterator(loop**, unsigned int) >>>> 354: 0000000000000000 748 FUNC WEAK DEFAULT 30 >>>> loop_iterator::loop_iterator(loop**, unsigned int) >>>> ... >>>> >>>> File: tree-cfg.o >>>> >>>> Symbol table '.symtab' contains 783 entries: >>>> Num: Value Size Type Bind Vis Ndx Name >>>> ... >>>> 385: 0000000000000000 0 NOTYPE LOCAL DEFAULT 5 >>>> loop_iterator::loop_iterator(loop**, unsigned int) >>>> ... >>>> 536: 0000000000000000 748 FUNC WEAK DEFAULT 34 >>>> loop_iterator::loop_iterator(loop**, unsigned int) >>>> ... >>>> 538: 0000000000000000 748 FUNC WEAK DEFAULT 34 >>>> loop_iterator::loop_iterator(loop**, unsigned int) >>>> ... >>>> >>>> When either loop_iterator::next or loop_iterator::loop_iterator >>>> inlined, bootstrap fails with the similar error. This patch >>>> works around the problem by not inlining those 2 functions. >>>> On Nehalem machine using "make -j8", without the patch, I got >>>> >>>> 17836.13user 638.12system 55:49.72elapsed >>>> >>>> for bootstrap and >>>> >>>> 32362.67user 4313.11system 1:29:59elapsed >>>> >>>> for running testsuite. With the patch, I got >>>> >>>> 7900.41user 640.39system 55:03.14elapsed >> >> It should be >> >> 17900.41user 640.39system 55:03.14elapsed >> >>>> for bootstrap and >>>> >>>> 31891.96user 4251.23system 1:31:41elapse >>>> >>>> for running testsuite. There is very little performance >>>> difference and the binaries are also a little bit smaller: >>>> >>>> 16787252 34920 1098648 17920820 1117334 build-x86_64-linux/gcc/cc1 >>>> 16809748 34920 1098648 17943316 111cb14 build-x86_64-linux.old/gcc/cc1 >>>> 19188340 35008 1126552 20349900 13683cc build-x86_64-linux/gcc/cc1objplus >>>> 18865150 35008 1121848 20022006 13182f6 build-x86_64-linux/gcc/cc1plus >>>> 19210836 35008 1126552 20372396 136dbac build-x86_64-linux.old/gcc/cc1objplus >>>> 18887646 35008 1121848 20044502 131dad6 build-x86_64-linux.old/gcc/cc1plus >>>> 17274027 44056 1104024 18422107 119195b build-x86_64-linux/gcc/f951 >>>> 17296523 44056 1104024 18444603 119713b build-x86_64-linux.old/gcc/f951 >>>> 17354837 51424 1105752 18512013 11a788d build-x86_64-linux/gcc/go1 >>>> 17377333 51424 1105752 18534509 11ad06d build-x86_64-linux.old/gcc/go1 >>>> 20815529 43928 6289304 27148761 19e41d9 build-x86_64-linux/gcc/gnat1 >>>> 20838025 43928 6289304 27171257 19e99b9 build-x86_64-linux.old/gcc/gnat1 >>>> 15944305 35688 1095064 17075057 1048b71 build-x86_64-linux/gcc/jc1 >>>> 15966801 35688 1095064 17097553 104e351 build-x86_64-linux.old/gcc/jc1 >>>> >>>> Should this patch be applied to restore LTO bootstrap with >>>> bootstrap-profile? >>> >>> I'd rather fix the bug than moving those functions out-of-line. Is it enough >>> to move the constructor and destructor out-of-line? >> >> No, it is independent of destructor. We need to move both constructor >> and loop_iterator::next out of line. > > Hm. The ICE is weird - I'm trying to reproduce now. I wonder whether > we can and should move update_ssa before execute_all_ipa_stmt_fixups > though. Or add two - likely the latter does something wrong. > > So disabling IPA-CP will likely fix this as well. !? This happens during WPA stage. Since when are we streaming in function bodies there?? #6 0x00000000009b8089 in ipa_merge_profiles ( dst=dst@entry=, src=src@entry=) at /space/rguenther/tramp3d/trunk/gcc/ipa-utils.c:702 702 cgraph_get_body (src); soo ... we mark the symbol for renaming here: /* Process the statements. */ for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si)) { gimple stmt; FOR_EACH_SSA_USE_OPERAND (use_p, stmt, i, SSA_OP_USE) { tree use = USE_FROM_PTR (use_p); if (!DECL_P (use)) continue; mark_for_renaming (use); on (gdb) call debug_gimple_stmt (si.ptr) # DEBUG ptr => &aloop where obviously 'aloop' is not an SSA use operand. (gdb) p verify_ssa_operands (si.ptr) $13 = false so the stmt is not up-to-date. Ok, so the issue is that aloop is not addressable. I think this is a more general issue then and nothing re-calls update_stmt on this DEBUG stmt without LTO. We can't have # DEBUG ptr => &aloop when we have rewritten aloop into SSA form. I'm thinking about how to fix it (and will try to create a testcase without LTO). Now for weekend ... I think update_address_taken needs to also consider the address-taken version. Try Richard. > Richard. > >> >> -- >> H.J. Index: gcc/tree-ssa.c =================================================================== --- gcc/tree-ssa.c (revision 205520) +++ gcc/tree-ssa.c (working copy) @@ -1329,6 +1336,10 @@ non_rewritable_mem_ref_base (tree ref) if (DECL_P (ref)) return NULL_TREE; + /* For DEBUG_STMTs we have to look through ADDR_EXPRs. */ + if (TREE_CODE (ref) == ADDR_EXPR) + ref = TREE_OPERAND (ref, 0); + while (handled_component_p (base)) base = TREE_OPERAND (base, 0);