From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37533 invoked by alias); 24 Mar 2015 14:22:25 -0000 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 Received: (qmail 37485 invoked by uid 48); 24 Mar 2015 14:22:22 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/65536] LTO line number information garbled Date: Tue, 24 Mar 2015 14:54:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg02585.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65536 --- Comment #11 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez from comment #9) > should reduce memory consumption (and perhaps speed) of the line_table by= a I meant "increase speed". >>From gcc-bugs-return-481444-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 24 14:38:10 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 106958 invoked by alias); 24 Mar 2015 14:38:09 -0000 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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 106865 invoked by uid 48); 24 Mar 2015 14:38:01 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/65536] LTO line number information garbled Date: Tue, 24 Mar 2015 14:56:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg02588.txt.bz2 Content-length: 1379 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65536 --- Comment #12 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Jakub Jelinek from comment #10) > You could just stream another table, containing the { file, line, column } > triplets, and stream location_t as indexes into this table (with 0/1 being > special for UNKNOWN_LOCATION and BUILTINS_LOCATION), or as pairs { > location_t, block }. Then on LTO reading, you could perhaps read the > location tables from multiple source files, merge them and for each of the > TUs build a hash_map mapping from the table indexes to location_t values. That is a bit of waste of memory, no? The "{ file, line, column }" table mi= ght be huge, presumably much larger than the actual line_tables. Thus, why not = just stream the line_tables directly? Then, you can stream the location_t as they are. When reading, it is possible to merge different TU line_tables into a single one quite efficiently (in the order of the maps and not in the order of triplets or maximum location_t). When adding each new TU line_table to the unified one, one keeps track of the last location_t assigned, and uses this later to convert out of order the old location_t from each TU line_table to= the new location_t of the new unified line_table. Perhaps I'm missing some detail and Dodji can comment on this idea. >>From gcc-bugs-return-481445-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 24 14:43:00 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 126465 invoked by alias); 24 Mar 2015 14:42:59 -0000 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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 126304 invoked by uid 48); 24 Mar 2015 14:42:49 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/65536] LTO line number information garbled Date: Tue, 24 Mar 2015 14:56:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg02589.txt.bz2 Content-length: 1045 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65536 --- Comment #13 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez from comment #12) > When reading, it is possible to merge different TU line_tables into a sin= gle > one quite efficiently (in the order of the maps and not in the order of > triplets or maximum location_t). When adding each new TU line_table to the > unified one, one keeps track of the last location_t assigned, and uses th= is > later to convert out of order the old location_t from each TU line_table = to > the new location_t of the new unified line_table. If the merge function is implemented within line-map.c, it could be extreme= ly efficient in terms of memory re-allocations. I think with the other approac= hes we end up reallocating the whole table many times because we do not know how many maps we need in advance (admittedly, anything else would be better than the current approach, because it seems LTO is creating a lot of empty maps). >>From gcc-bugs-return-481443-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 24 14:34:13 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 61077 invoked by alias); 24 Mar 2015 14:34:13 -0000 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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 53777 invoked by uid 48); 24 Mar 2015 14:34:09 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression Date: Tue, 24 Mar 2015 14:56:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg02587.txt.bz2 Content-length: 3319 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rguenth at gcc dot gnu.org --- Comment #14 from Richard Biener --- (In reply to Jan Hubicka from comment #11) > Sorry, the number of clobbers drops at DSE1, not during ehcleanup2, I just > messed up my grep. > > I tried the following patch: > > Index: passes.def > =================================================================== > --- passes.def (revision 221541) > +++ passes.def (working copy) > @@ -87,6 +87,7 @@ along with GCC; see the file COPYING3. > NEXT_PASS (pass_build_ealias); > NEXT_PASS (pass_fre); > NEXT_PASS (pass_merge_phi); > + NEXT_PASS (pass_dse); > NEXT_PASS (pass_cd_dce); > NEXT_PASS (pass_early_ipa_sra); > NEXT_PASS (pass_tail_recursion); > > This brings number of CLOBBER statements at release_ssa time down to 7392 > (50% reduction). A nice effect of this patch is that it tends to simplify > destructors often to empty to make them more inlinable: > > ObserverEvent::~ObserverEvent() (struct ObserverEvent * const this) > { > : > - this_2(D)->_vptr.ObserverEvent = &MEM[(void *)&_ZTV13ObserverEvent + 16B]; > MEM[(struct &)this_2(D)] ={v} {CLOBBER}; > return; > > saves a lot of the clobbers: > Engine<3, double, ExpressionTag Reference, Vector<3, double, Full>, ViewEngine<3, > IndexFunction CartesianTag, 3> >::PositionsFunctor> > > >, Scalar > > > > > >::~Engine() (struct Engine * const this) > { > : > - MEM[(struct &)this_2(D) + 32] ={v} {CLOBBER}; > - MEM[(struct &)this_2(D) + 32] ={v} {CLOBBER}; > - MEM[(struct &)this_2(D) + 8] ={v} {CLOBBER}; > - MEM[(struct &)this_2(D) + 8] ={v} {CLOBBER}; > - MEM[(struct &)this_2(D) + 8] ={v} {CLOBBER}; > - MEM[(struct &)this_2(D)] ={v} {CLOBBER}; > - MEM[(struct &)this_2(D)] ={v} {CLOBBER}; > - MEM[(struct &)this_2(D)] ={v} {CLOBBER}; > + MEM[(struct &)this_1(D)] ={v} {CLOBBER}; > return; > > which is especially nice for LTO streaming. > > and saves about 7% of code apparently after inlining: > > $ wc -l *copyprop2 > 200189 tramp3d-v4.ii.085t.copyprop2 > $ wc -l ../5/*copyprop2 > 215060 ../5/tramp3d-v4.ii.084t.copyprop2 > > Even though the inline decisions does not seem to be changed considerably > (at least on tramp3d). Yeah, clobbers don't account for anything for size/inline estimates (well, I hope so!). And yes, doing DSE early is quite an old idea... we should revisit it next stage1. > On unrelated note I noticed PR65502 > > Still I guess this does not really explain the origin of regression in > statement count relative to 4.9... No idea. I'll have to look myself - the &X + 4 vs. &MEM[&X, 4] is very reecent so it can't be blamed for the regression. But it might be blamed for the number of stmt differences - but only from the very beginning. That is, I can't see how the difference shows in .ssa but not in .cfg.