[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 Andreas Tobler andreast at gcc dot gnu.org changed: What|Removed |Added CC||andreast at gcc dot gnu.org --- Comment #19 from Andreas Tobler andreast at gcc dot gnu.org 2012-11-17 10:01:05 UTC --- The commit r193139, comment #14, breaks bootstrap on powerpc64-*-* with --disabled-checking. Seen here on powerpc64-unknown-freebsd10.0 and Peter Bergner confirmed the same break on powerp64-*-linux*. Bootstrap comparison failure! gcc/tree-ssa-forwprop.o differs ._ZL33ssa_forward_propagate_and_combinev+0x2548 -9658:e8 89 00 09 ldu r4,8(r9) -965c:39 08 00 01 addir8,r8,1 +9658:39 08 00 01 addir8,r8,1 +965c:e8 89 00 09 ldu r4,8(r9) 9660:4b ff ff d0 b 9630
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #20 from Andreas Tobler andreast at gcc dot gnu.org 2012-11-17 12:36:16 UTC --- Just for clarification, the following commits (after #14) in this PR did not resolve the bootstrap issue. I was on r193501 when I first encountered the comparison failure and then I went back until the comparison failure went away.
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #21 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-11-18 01:56:04 UTC --- This doesn't look like something the bugfix may have caused, but rather as some latent bug exposed by that patch, like the latent bug fixed in comment 7. Anyway, a preprocessed code that would enable me to look into this with a cross compiler would be appreciated. TIA,
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-06 09:45:58 UTC --- Not completely. Apparently the new testcase fails on both x86_64-linux and i686-linux with -O1 -g. The reason for that is that with -O1 jump threading isn't performed, and the bb duplication is done in tree-ssa-loop-ch.c instead. So, I'd say we want to do something similar to what propagate_threaded_block_debug_into does, in copy_loop_headers or so, on copied_bbs, copying debug stmts into the loop body (exit-dest before the gimple_duplicate_sese_region call). Calling p propagate_threaded_block_debug_into (exit-dest, entry-dest) from the debugger fixed the testcase for -O1 -g.
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #17 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-11-06 17:59:04 UTC --- Author: aoliva Date: Tue Nov 6 17:58:52 2012 New Revision: 193251 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193251 Log: PR debug/54693 * tree-ssa-threadedge.c (propagate_threaded_block_debug_into): Use a stack vector before allocating a pointer set. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-threadedge.c
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-07 07:50:07 UTC --- Author: jakub Date: Wed Nov 7 07:50:01 2012 New Revision: 193281 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193281 Log: PR debug/54693 * tree-flow.h (propagate_threaded_block_debug_into): New prototype. * tree-ssa-threadedge.c (propagate_threaded_block_debug_into): No longer static. * tree-ssa-loop-ch.c (copy_loop_headers): Use it. * gcc.dg/guality/pr54693-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/guality/pr54693-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-loop-ch.c trunk/gcc/tree-ssa-threadedge.c
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #13 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-11-04 18:44:18 UTC --- Author: aoliva Date: Sun Nov 4 18:44:13 2012 New Revision: 193138 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193138 Log: PR debug/54693 * tree-ssa-threadedge.c (propagate_threaded_block_debug_into): New, rewritten from debug stmt copying code... (thread_around_empty_block): ... removed from here. (thread_across_edge): Call propagate_threaded_block_debug_into. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-threadedge.c
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #14 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-11-04 18:44:32 UTC --- Author: aoliva Date: Sun Nov 4 18:44:25 2012 New Revision: 193139 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193139 Log: PR debug/54693 * tree-ssa-loop-ivopts.c (remove_unused_ivs): Emit debug temps for dropped IV sets. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-11-04 22:09:12 UTC --- Fixed
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #12 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-30 23:47:44 UTC --- Author: aoliva Date: Tue Oct 30 23:47:35 2012 New Revision: 193003 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193003 Log: PR debug/54551 PR debug/54693 * valtrack.c (dead_debug_promote_uses): Assert-check that global used bit was clear and initialize entry unconditionally. Modified: trunk/gcc/ChangeLog trunk/gcc/valtrack.c
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #7 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-29 19:26:21 UTC --- Author: aoliva Date: Mon Oct 29 19:26:16 2012 New Revision: 192957 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192957 Log: PR debug/54693 * config/i386/i386.c (add_parameter_dependencies): Stop backward scan at the insn before the incoming head. (ix86_dependencies_evaluation_hook): Skip debug insns. Stop if first_arg is head. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #8 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-29 19:27:11 UTC --- Author: aoliva Date: Mon Oct 29 19:27:09 2012 New Revision: 192958 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192958 Log: PR debug/54693 * loop-unroll.c (loop_exit_at_end_p): Skip debug insns. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-unroll.c
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #9 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-29 19:27:39 UTC --- Author: aoliva Date: Mon Oct 29 19:27:31 2012 New Revision: 192959 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192959 Log: PR debug/54551 PR debug/54693 * valtrack.c (dead_debug_global_find): Accept NULL dtemp. (dead_debug_global_insert): Return new entry. (dead_debug_global_replace_temp): Return early if REG is no longer in place, or if dtemp was already substituted. (dead_debug_promote_uses): Insert for all defs and replace all debug uses at once. (dead_debug_local_finish): Release used after promotion. (dead_debug_insert_temp): Stop if dtemp is NULL. Modified: trunk/gcc/ChangeLog trunk/gcc/valtrack.c
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #10 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-29 19:36:52 UTC --- Author: aoliva Date: Mon Oct 29 19:36:47 2012 New Revision: 192961 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192961 Log: gcc/ChangeLog: PR debug/54693 * tree-ssa-threadedge.c (thread_around_empty_block): Copy debug temps from predecessor before threading. gcc/testsuite/ChangeLog: PR debug/54693 * gcc.dg/guality/pr54693.c: New. Added: trunk/gcc/testsuite/gcc.dg/guality/pr54693.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadedge.c
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #11 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-29 19:37:31 UTC --- Author: aoliva Date: Mon Oct 29 19:37:25 2012 New Revision: 192962 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192962 Log: PR debug/54693 * gcc/valtrack.c (dead_debug_insert_temp): Defer rescan of newly-emitted debug insn. Modified: trunk/gcc/ChangeLog trunk/gcc/valtrack.c
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-10-26 AssignedTo|unassigned at gcc dot |aoliva at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #6 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-26 07:16:35 UTC --- Patchset for trunk posted: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02379.html
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-19 12:34:14 UTC --- Thanks, the threadedge patch looks reasonable (I think gimple_location on debug stmts is ignored, so we don't need to drop it). As for ivopts, there is no use in these cases. We'd either need to add debug uses of IVs as a special set of uses (perhaps in a different vector), that wouldn't be used for decision of which IVs to keep/use, but just for computation of the best candidate for it (where for debug info best is something very different from best for code, for debug info smaller cost is as small as possible expression, as few address expressions in it as possible, as few SSA_NAMEs as possible). Or I guess another alternative for unused IVs used in debug stmts is do what your loop does (but drop the PHI check and do it for all unused IVs?; in the particular testcase before your threadedge change the DEBUG stmts use i_10, which is i_16 + 1 (where i_16 is set in PHI i_10, 0), so it wouldn't do anything). You can build an artificial temporary use object, get_computation_at only uses the iv field of it (so just struct iv_use use; memset (use, 0, sizeof (use)); use.iv = info-iv;, for stmt I'd use for PHI setters gsi_after_labels stmt, for normal assignments next stmt after the setter it if any. And for cand perhaps go through all of the (or just a subsect of) iv_cands that are iv_use (data, i)-selected for some i. Perhaps we can first search for a cand-iv with equal step to the unused iv if any (and prefer integer bases over more complex ones, on this testcase the removed iv used by some DEBUG stmts is: ssa name i_10 type int base 1 step 1 is a biv and iv_cands that are selected by any uses are: type unsigned long base (unsigned long) arr step 1 base object (void *) arr and type unsigned int base 48 step 1 where better is to use the second one, both because it has an integer base, and because TYPE_MODE of its type is identical to TYPE_MODE of the iv (so no extension/truncation is needed). get_computation_at returns possibly large tree, so we need to gimplify it into perhaps series of debug temps, finally assign to a debug temp after the setter stmt, then rewrite all the debug stmt uses to use this debug temp.
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-19
13:49:03 UTC ---
What I had in mind for ivopts is roughly this. Not sure about the last
argument to get_computation_at. For normal statements I'd hope it shouldn't
make a difference, the stmt that initializes the unused iv should hopefully not
be in any way related to the place where increment of the new iv will happen,
for phis it needs more investigation.
And I don't see any infrastructure to gimplify a larger expression into several
debug temporaries with simpler expressions.
--- gcc/tree-ssa-loop-ivopts.c.jj2012-09-12 10:57:02.629762526 +0200
+++ gcc/tree-ssa-loop-ivopts.c2012-10-19 15:35:19.631230006 +0200
@@ -6422,7 +6422,76 @@ remove_unused_ivs (struct ivopts_data *d
!info-inv_id
!info-iv-have_use_for
!info-preserve_biv)
-bitmap_set_bit (toremove, SSA_NAME_VERSION (info-iv-ssa_name));
+{
+ bitmap_set_bit (toremove, SSA_NAME_VERSION (info-iv-ssa_name));
+
+ if (MAY_HAVE_DEBUG_STMTS
+ SSA_NAME_DEF_STMT (info-iv-ssa_name))
+{
+ tree comp = NULL_TREE;
+ imm_use_iterator imm_iter;
+ use_operand_p use_p;
+ gimple stmt;
+
+ FOR_EACH_IMM_USE_STMT (stmt, imm_iter, info-iv-ssa_name)
+{
+ if (!gimple_debug_bind_p (stmt))
+continue;
+
+ if (comp == NULL_TREE)
+{
+ struct iv_use dummy_use;
+ struct iv_cand *best_cand = NULL, *cand;
+ unsigned i, best_pref = 0, cand_pref;
+
+ memset (dummy_use, 0, sizeof (dummy_use));
+ dummy_use.iv = info-iv;
+ for (i = 0; i n_iv_uses (data) i 64; i++)
+{
+ cand = iv_use (data, i)-selected;
+ if (cand == best_cand)
+continue;
+ cand_pref = operand_equal_p (cand-iv-step,
+ info-iv-step, 0)
+ ? 4 : 0;
+ cand_pref
++= TYPE_MODE (TREE_TYPE (cand-iv-base))
+ == TYPE_MODE (TREE_TYPE (info-iv-base))
+ ? 2 : 0;
+ cand_pref
++= TREE_CODE (cand-iv-base) == INTEGER_CST
+ ? 1 : 0;
+ if (best_cand == NULL || best_pref cand_pref)
+{
+ best_cand = cand;
+ best_pref = cand_pref;
+}
+}
+ if (best_cand == NULL)
+BREAK_FROM_IMM_USE_STMT (imm_iter);
+
+ comp = get_computation_at (data-current_loop,
+ dummy_use, best_cand,
+ SSA_NAME_DEF_STMT (info-iv-ssa_name));
+ if (comp == NULL_TREE)
+BREAK_FROM_IMM_USE_STMT (imm_iter);
+ /* gimplify into DEBUG temporaries expression comp,
+ insert immediately after
+ SSA_NAME_DEF_STMT (info-iv-ssa_name).
+ Set comp to the final DEBUG_EXPR_DECL. */
+#if 1
+ (void) comp;
+ BREAK_FROM_IMM_USE_STMT (imm_iter);
+#endif
+}
+
+ FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
+SET_USE (use_p, comp);
+
+ update_stmt (stmt);
+}
+}
+}
}
release_defs_bitset (toremove);
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #3 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-10-14 21:19:00 UTC --- Created attachment 28447 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28447 Work in progress patch This patch improves jump threading so that it won't drop debug info on the floor as often as it does now, copying the debug bind stmts of the jump-threaded block to the new confluence destination, so that the copies will be updated so as to bind to the new PHI nodes, if needed. This preserved variable i longer than before within the compilation, but it was stll lost in ivopts. I started looking into the ivopts loss: we need to rewrite at least the PHI nodes we're removing in terms of the remaining ivs, but even though I wrote all the needed infrastructure to adjust the debug info bindings, I couldn't figure out how to express the dropped ivs in terms of the remaining ones. I suppose someone more familiar with tree-ivopts might have some idea, so I decided not to spend more time trying to figure it out. This is as far as I could get on my own. I hope this helps.
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-04 06:09:48 UTC --- As a quick hack just for this testcase we might perhaps do something in jump threading code, if we have a DEBUG stmt based on a PHI result and are splitting it up, look if it is the last DEBUG stmt for the variable in the threaded bb and if so, consider adding a DEBUG stmt also to the fallthru bb after the threaded block, based on its PHI. For the general solution, didn't give it much thought yet, but so far I was thinking about a pass that would analyze on GIMPLE (perhaps shortly before expansion) all DEBUG stmts and work similarly to tree-into-ssa.c algorithm (just simplified by performing it just once, never incrementally). SSA_NAME_VERSION for the debug stmt lhs decls could be some integer recorded perhaps as gimple_uid on the debug stmts, we'd track the current definition of each debug stmt lhs uid, and instead of inserting PHI nodes we could: 1) look for existing PHI node for the var mentioned in the debug stmt rhs, use that if exists 2) in bb with few incoming edges, look for existing PHI node with constant PHI arguments where for different current defs of some debug stmt lhs uid the constants have different values, like: bb 7: DEBUG i = D#12 goto bb 9; bb 8: DEBUG i = i_17 bb 9: z = PHI 7(7), 19(8) We can then insert something like DEBUG i = z == 7 ? D#12 : i_17 3) otherwise punt. Perhaps 2) would need some var-tracking changes, I'm afraid unavailability of a VALUE for either of the branches of the COND_EXPR would reset it all. But at least 1) could work.
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-01 15:26:10 UTC --- In VRP it is jump threading that performs the first CFG transformation, and the second one happens as two merge_block opportunities during cleanup_tree_cfg. Doing the new DEBUG stmt insertion upon merge_blocks would be weird, perhaps some pass should just in addition to what it does now try to detect at least the simple cases, where at the end of more than one predecessor block are live debug stmts for some decl, and they use invariants or SSA_NAMEs that appear together in some PHI - then adding a DEBUG stmt at the start of the bb with a PHI might improve debug info quality, something var-tracking won't be able to figure out due to the conditional.
