On Fri, Nov 29, 2013 at 1:47 PM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On Fri, Nov 29, 2013 at 1:27 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>> On Fri, Nov 29, 2013 at 2:26 AM, Richard Biener
>> <richard.guent...@gmail.com> wrote:
>>> On Thu, Nov 28, 2013 at 6:22 PM, H.J. Lu <hongjiu...@intel.com> 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 <http://gcc.gnu.org/bugs.html> 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=<cgraph_node* 0x7fffe8d343d8 "__base_ctor ">,
src=src@entry=<cgraph_node* 0x7fffe8d55520 "__base_ctor ">)
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
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);
Richard.
> Richard.
>
>>
>> --
>> H.J.
