[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
--- Comment #15 from rakdver at gcc dot gnu dot org 2006-04-09 23:51
---
(In reply to comment #14)
> (In reply to comment #11)
> > I updated the patch for current mainline, but it still has issues for some
> > common uses of loops:
> >
> > void foo(int *ie, int *je, double *x)
> > {
> > int i, j;
> > for (j=0; j<*je; ++j)
> > for (i=0; i<*ie; ++i)
> > x[i+j] = 0.0;
> > }
> >
> > After loop header copying we have
> >
> > if (*je > 0)
> > for (j=0; j<*je; ++j)
> > if (*ie > 0)
> > for (i=0; i<*ie; ++i)
> > x[i+j ] = 0.0;
> >
> > note how in this form we see the condition *ie > 0 not invariant wrt the
> > outer loop (because it does a memory load), but if we would run load-PRE
> > between loop header copying and guard hoisting we would get
>
> actually, thinking about it again, it should suffice to teach
> invariant_without_guard_p about invariant memory loads, and this should just
> work.
It basically does, the only other problem is that we are not able to determine
that the outer loop is not infinite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
--- Comment #16 from rakdver at gcc dot gnu dot org 2006-04-10 00:03 --- Created an attachment (id=11231) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11231&action=view) Updated version of the patch, also handling invariant memory references -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #33 from rakdver at gcc dot gnu dot org 2006-04-12 12:20 --- Created an attachment (id=11248) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11248&action=view) Patch to speed up update_ssa This patch makes update_ssa significantly faster in cases like this (when update_ssa is called often), by ensuring that we do not perform unnecessary expensive tasks (walking all statements or ssa names) each time update_ssa is called. Several more improvements are possible, especially in the phi insertion phase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #37 from rakdver at gcc dot gnu dot org 2006-04-14 00:06 --- Created an attachment (id=11262) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11262&action=view) Updated version of the patch This patch (this time more or less a final version, bootstrapped & regtested on ia64) basically solves the problem with incremental updates (see the timings below -- on x86_64 with disabled checking, on a bit smaller testcase that does not eat all the memory on the machine). I will cut it into several parts and start submitting it. Timings without the patch: tree SSA rewrite : 94.74 (52%) usr 0.02 ( 1%) sys 94.97 (35%) wall 11245 kB ( 3%) ggc tree SSA incremental : 29.04 (16%) usr 0.01 ( 0%) sys 28.85 (11%) wall 5045 kB ( 1%) ggc dominance frontiers : 5.26 ( 3%) usr 0.01 ( 0%) sys 5.32 ( 2%) wall 0 kB ( 0%) ggc TOTAL : 183.92 2.71 268.10 350366 kB Timings with the patch: tree SSA rewrite : 2.42 ( 4%) usr 0.01 ( 0%) sys 2.26 ( 1%) wall 11247 kB ( 3%) ggc tree SSA incremental : 3.79 ( 6%) usr 0.04 ( 1%) sys 4.01 ( 2%) wall 5754 kB ( 2%) ggc dominance frontiers : 1.35 ( 2%) usr 0.00 ( 0%) sys 1.26 ( 1%) wall 0 kB ( 0%) ggc TOTAL : 64.84 3.13 175.84 351069 kB -- rakdver at gcc dot gnu dot org changed: What|Removed |Added Attachment #11248|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug c/27214] The C frontend introduces undefined pointer overflow
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-04-19 16:32 --- I do not think this PR is invalid: int a[100]; int *p = &a[50]; p - 1 is well defined, and points to 50 - 1 th element of a, as standard specifies p + (-1) is also well defined, and points to 50 + (-1) th element, again according to standard. p + (unsigned) -1 is undefined, as there is no 50 + 4294967295 th element in a (the standard specifies that there cannot be any overflow in the computation). Andrew, please do not mark PRs as invalid until the people involved in the discussion do not agree on the common interpretation of the standard. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214
[Bug tree-optimization/27283] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-04-25 01:20:53 |2006-04-27 05:48:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27283
[Bug rtl-optimization/27291] [4.2 regression] verify_flow_info failed: too many outgoing branch edges from bb 4
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-04-25 01:30:12 |2006-04-27 06:26:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27291
[Bug tree-optimization/27283] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-04-27 15:00 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01044.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg01044.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27283
[Bug tree-optimization/27144] [4.2 regression] segfault with -O2 on x86_64 (and powerpc64)
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-04-13 17:01:44 |2006-04-27 16:04:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27144
[Bug tree-optimization/27144] [4.2 regression] segfault with -O2 on x86_64 (and powerpc64)
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-04-27 17:42 --- This is more or less dup of PR23434 (the fix for it is not quite correct). I am testing a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27144
[Bug rtl-optimization/27291] [4.2 regression] verify_flow_info failed: too many outgoing branch edges from bb 4
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-04-27 22:21 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01058.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg01058.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27291
[Bug tree-optimization/27144] [4.2 regression] segfault with -O2 on x86_64 (and powerpc64)
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-04-28 08:44 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01078.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg01078.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27144
[Bug tree-optimization/27144] [4.2 regression] segfault with -O2 on x86_64 (and powerpc64)
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-05-01 19:42 --- Subject: Bug 27144 Author: rakdver Date: Mon May 1 19:42:01 2006 New Revision: 113425 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113425 Log: PR tree-optimization/27144 * tree-ssa-loop-niter.c (derive_constant_upper_bound): New function. (record_estimate): Only record constant upper bound. (infer_loop_bounds_from_undefined): Call compute_estimated_nb_iterations just once. (proved_non_wrapping_p): Renamed to ... (n_of_executions_at_most): ... this. Expect bound to be a constant. (convert_step_widening, scev_probably_wraps_p): Call n_of_executions_at_most instead of proved_non_wrapping_p. (substitute_in_loop_info): Do not replace values in bounds. * cfgloop.h (struct nb_iter_bound): Remove "additional" field. Update comments. * gcc.dg/tree-ssa/loop-16.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-16.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloop.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27144
[Bug tree-optimization/27283] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-05-01 20:06 --- Subject: Bug 27283 Author: rakdver Date: Mon May 1 20:05:57 2006 New Revision: 113427 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113427 Log: PR tree-optimization/27283 * tree-ssa-loop-ivopts.c (struct nfe_cache_elt): Store just trees, not whole # of iteration descriptions. (niter_for_exit): Return just # of iterations. Fail if # of iterations uses abnormal ssa name. (niter_for_single_dom_exit): Ditto. (find_induction_variables, may_eliminate_iv): Expect niter_for_exit to return just the number of iterations. * g++.dg/tree-ssa/pr27283.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr27283.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27283
[Bug rtl-optimization/27291] [4.2 regression] verify_flow_info failed: too many outgoing branch edges from bb 4
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-05-01 20:46 --- Subject: Bug 27291 Author: rakdver Date: Mon May 1 20:46:22 2006 New Revision: 113430 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113430 Log: PR rtl-optimization/27291 * loop-doloop.c (add_test, doloop_modify): Handle the case condition is folded to a constant. * g++.dg/tree-ssa/pr27291.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr27291.C Modified: trunk/gcc/ChangeLog trunk/gcc/loop-doloop.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27291
[Bug tree-optimization/26304] [4.2 Regression] 25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and powerpc-darwin
--- Comment #22 from rakdver at gcc dot gnu dot org 2006-05-02 07:56 --- (In reply to comment #14) > Hmm, I wonder if the following loop in scev_probably_wraps_p is wrong. > > estimate_numbers_of_iterations_loop (loop); > for (bound = loop->bounds; bound; bound = bound->next) > if (proved_non_wrapping_p (at_stmt, bound, type, valid_niter)) > return false; > > it says that if one bounds does not wrap, then all variables asked about don't > which is not true. this piece of code seems OK to me (modulo that proved_non_wrapping_p was quite missleading way to name that function). What it does is that we know that the loop is executed at most BOUND times, and that the variable will not wrap for at least VALID_NITER iterations; therefore, if we are able to prove that VALID_NITER > BOUND for any of the bounds, we know that the variable does not wrap. There is probaby off-by-one error in one of the functions. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-04-11 23:17:57 |2006-05-02 07:56:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26304
[Bug tree-optimization/26304] [4.2 Regression] 25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and powerpc-darwin
--- Comment #23 from rakdver at gcc dot gnu dot org 2006-05-02 08:57 --- Somehow, we record that the loop iterates at most once, which obviously leads to problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26304
[Bug tree-optimization/27144] [4.2 regression] segfault with -O2 on x86_64 (and powerpc64)
--- Comment #11 from rakdver at gcc dot gnu dot org 2006-05-02 12:42 --- The problem is that unsigned_type_for returns a size_type for pointers, and that happens to be signed for fortran. I am not sure whether this is not a bug in fortran frontend -- I think some places in gcc assume that size_t is unsigned (and standard specifies this). I am not sure how this could pass through my testing; this must break a lot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27144
[Bug tree-optimization/27392] [4.2 Regression] GCC error: in n_of_executions_at_least, at tree-ssa-loop-niter.c:1772
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-05-04 10:49 --- Fixed. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27392
[Bug tree-optimization/27335] [4.0/4.1/4.2 regression] ICE in get_loop_body
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-04-30 05:55:08 |2006-05-05 12:16:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27335
[Bug tree-optimization/26304] [4.2 Regression] 25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and powerpc-darwin
--- Comment #24 from rakdver at gcc dot gnu dot org 2006-05-08 11:18 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00290.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg00290.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26304
[Bug rtl-optimization/27335] [4.0/4.1/4.2 regression] ICE in get_loop_body
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-05-08 17:33 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00308.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg00308.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27335
[Bug rtl-optimization/27335] [4.0/4.1/4.2 regression] ICE in get_loop_body
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-05-09 09:10 --- Subject: Bug 27335 Author: rakdver Date: Tue May 9 09:10:15 2006 New Revision: 113648 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113648 Log: PR rtl-optimization/27335 * loop-unroll.c (peel_loops_completely): Use loops->parray to walk the loops. * gcc.dg/pr27335.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr27335.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-unroll.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27335
[Bug tree-optimization/27003] [4.0 Regression] ivcanon bug
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-10 13:59:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27003
[Bug tree-optimization/27548] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-11 09:22:21 |2006-05-11 10:56:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27548
[Bug tree-optimization/27003] [4.0 Regression] ivcanon bug
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-05-11 14:19 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00463.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg00463.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27003
[Bug tree-optimization/27548] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-05-12 14:46 --- Can also be reproduced on i686. Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00511.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg00511.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27548
[Bug tree-optimization/27003] [4.0 Regression] ivcanon bug
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-05-13 19:46 --- Subject: Bug 27003 Author: rakdver Date: Sat May 13 19:45:56 2006 New Revision: 113742 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113742 Log: PR tree-optimization/27003 * tree.c (build_int_cst_type): Avoid shift by size of type. * gcc.dg/pr27003.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr27003.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27003
[Bug rtl-optimization/27335] [4.0/4.1 regression] ICE in get_loop_body
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-05-13 22:11 --- Subject: Bug 27335 Author: rakdver Date: Sat May 13 22:10:56 2006 New Revision: 113746 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113746 Log: PR rtl-optimization/27335 * loop-unroll.c (peel_loops_completely): Use loops->parray to walk the loops. * gcc.dg/pr27335.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr27335.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/loop-unroll.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27335
[Bug rtl-optimization/27335] [4.0/4.1 regression] ICE in get_loop_body
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-05-13 22:12 --- Subject: Bug 27335 Author: rakdver Date: Sat May 13 22:12:13 2006 New Revision: 113747 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113747 Log: PR rtl-optimization/27335 * loop-unroll.c (peel_loops_completely): Use loops->parray to walk the loops. * gcc.dg/pr27335.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr27335.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/loop-unroll.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27335
[Bug tree-optimization/26719] [4.1/4.2 Regression] Computed (integer) table changes with -O
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-05-14 14:49 ---
(In reply to comment #4)
> Created an attachment (id=11146)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11146&action=view) [edit]
> first step
>
> with this patch scev returns (int) (char) {0,+,1} but then
> chrec_convert_aggressive is removing the casts and the result
> is just {0,+,1}.
This sounds suspicious, the result after chrec_convert_aggressive
should be (int) [0,+,1] (where the type of 0 and 1 is char).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #38 from rakdver at gcc dot gnu dot org 2006-05-15 18:25 --- Subject: Bug 26830 Author: rakdver Date: Mon May 15 18:24:55 2006 New Revision: 113799 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113799 Log: PR tree-optimization/26830 * tree-into-ssa.c (struct ssa_name_info): Add age field. (info_for_ssa_name, current_info_for_ssa_name_age, blocks_to_update): New variables. (get_ssa_name_ann): Use info_for_ssa_name instead of SSA_NAME_AUX. (clear_ssa_name_info, initialize_flags_in_bb, mark_block_for_update): New functions. (mark_def_sites, rewrite_stmt): Assert that blocks_to_update is NULL. (insert_phi_nodes_for, mark_use_interesting, prepare_block_for_update, prepare_def_site_for): Use mark_block_for_update. (mark_def_interesting): Assert that the processed block is marked in blocks_to_update. Do not take blocks argument. (prepare_use_sites_for, prepare_names_to_update): Do not take blocks argument. (rewrite_update_init_block, rewrite_update_stmt): Only process blocks with statements to rewrite. (delete_update_ssa): Do not clear SSA_NAME_AUX. (update_ssa): Initialize and free blocks_to_update. Do not clear flags on statements. Do not use blocks bitmap. * tree.h (SSA_NAME_AUX): Removed. (struct tree_ssa_name): Removed aux field. * print-tree.c (print_node): Do not print SSA_NAME_AUX. Modified: trunk/gcc/ChangeLog trunk/gcc/print-tree.c trunk/gcc/tree-into-ssa.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #39 from rakdver at gcc dot gnu dot org 2006-05-15 21:56 --- Most of the time is now spent in global alloc (30% of wall time) and rtl loop invariant motion (also about 30%). Almost all the time of rtl lim is in df analysis. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added CC||zadeck at naturalbridge dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug tree-optimization/27548] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-05-17 11:33 --- Subject: Bug 27548 Author: rakdver Date: Wed May 17 11:33:00 2006 New Revision: 113853 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113853 Log: PR tree-optimization/27548 * tree-scalar-evolution.c (scev_const_prop): Do not prolong life range of ssa names that appear on abnormal edges. * tree-ssa-loop-ivopts.c (contains_abnormal_ssa_name_p): Export. * tree-flow.h (contains_abnormal_ssa_name_p): Declare. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27548
[Bug tree-optimization/27639] [4.1/4.2 regression] VRP miscompilation of simple loop
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-05-17 13:02 --- (In reply to comment #2) > scev_probably_wraps_p returns false because we recorded a max of 49 iteration > from > > (gdb) call debug_generic_expr ( loop->bounds->next->at_stmt) > D.1993_10 = (charD.3) ixD.1987_7 > > using infer_loop_bounds_from_undefined which is of course bogus. what is the scev of D.1993_10 in this statement? It should be (char) [5, +, ~0u], if it is anything else, there is a problem in scev analysis. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
[Bug tree-optimization/27639] [4.1/4.2 regression] VRP miscompilation of simple loop
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-05-17 13:11 ---
> It's
>
> (set_scalar_evolution
> (scalar = D.1993_10)
> (scalar_evolution = {79, +, -1}_1))
> )
Then it is a bug in chrec_convert (might also be related to PR 27619).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
[Bug tree-optimization/27639] [4.1/4.2 regression] VRP miscompilation of simple loop
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-05-17 13:12 ---
(In reply to comment #8)
> > It's
> >
> > (set_scalar_evolution
> > (scalar = D.1993_10)
> > (scalar_evolution = {79, +, -1}_1))
> > )
>
>
> Then it is a bug in chrec_convert (might also be related to PR 27619).
sorry, I meant PR26719.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
[Bug tree-optimization/27639] [4.1/4.2 regression] VRP miscompilation of simple loop
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-05-17 13:40
---
(In reply to comment #12)
> Ok, the patch fixes this PR, but not PR26719.
>
> Index: tree-chrec.c
> ===
> --- tree-chrec.c(revision 113852)
> +++ tree-chrec.c(working copy)
> @@ -1150,7 +1150,7 @@ chrec_convert (tree type, tree chrec, tr
> 1, 2, ..., 127, -128, ... The result should not be
> {(schar)1, +, (schar)1}_x, but instead, we should keep the
> conversion: (schar) {(uchar)1, +, (uchar)1}_x. */
> - if (scev_probably_wraps_p (type, base, step, at_stmt, loop,
> + if (scev_probably_wraps_p (ct, base, step, at_stmt, loop,
> &dummy, &dummy))
> goto failed_to_convert;
>
>
although I think the idea of the fix is OK, you must be more careful --
scev_probably_wraps_p does computations with base and step in type,
so you cannot just pass another type to it.
The problem with fold_convert is that currently it is a patch over patch; it
checks for overflows twice (once using scev_probably_wraps_p and once again
in convert_step_widening), but neither of the checks is exactly what is needed.
I recall having this fixed once (perhaps on killloop branch), I will check
whether I can find the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
[Bug tree-optimization/27639] [4.1/4.2 regression] VRP miscompilation of simple loop
--- Comment #17 from rakdver at gcc dot gnu dot org 2006-05-17 13:54 --- (In reply to comment #16) > (bugzilla doesn't like my mail-replies it seems) > > Currently we have a type-mismatch type vs. ct, where ct is the canonical type > for step/base. I guess this was a typo. Umm.. right, it is wrong currently. Nevertheless, as far as I understand the comment above the call, this is not a typo, but intention (to check that the scev in the new type does not wrap, otherwise the comment does not make sense). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
[Bug tree-optimization/26719] [4.1/4.2 Regression] Computed (integer) table changes with -O
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-05-20 19:27 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01032.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg01032.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
[Bug tree-optimization/27639] [4.1/4.2 regression] VRP miscompilation of simple loop
--- Comment #24 from rakdver at gcc dot gnu dot org 2006-05-20 19:27 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01032.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg01032.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
[Bug rtl-optimization/27735] [4.2 Regression] ice with -O3 on legal code [unswitch]
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-23 04:12:58 |2006-05-23 10:15:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27735
[Bug rtl-optimization/27735] [4.2 Regression] ice with -O3 on legal code [unswitch]
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-05-24 09:54 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01229.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg01229.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27735
[Bug tree-optimization/27639] [4.1/4.2 regression] VRP miscompilation of simple loop
--- Comment #25 from rakdver at gcc dot gnu dot org 2006-05-24 22:55 --- Subject: Bug 27639 Author: rakdver Date: Wed May 24 22:55:15 2006 New Revision: 114057 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114057 Log: PR tree-optimization/27639 PR tree-optimization/26719 * tree-vrp.c (adjust_range_with_scev): Use scev_direction and adjust call to scev_probably_wraps_p. * tree-ssa-loop-niter.c (compare_trees, convert_step_widening, used_in_pointer_arithmetic_p, convert_step): Removed. (nowrap_type_p): New function. (scev_probably_wraps_p): Rewritten. * tree-scalar-evolution.c (instantiate_parameters_1): Do not call chrec_convert if chrec_convert_aggressive might have been used. * tree-chrec.c (convert_affine_scev, chrec_convert_1, scev_direction): New functions. (chrec_convert): Changed to a wrapper over chrec_convert_1. * tree-ssa-loop-ivopts.c (idx_find_step): Use convert_affine_scev instead of convert_step. * tree-flow.h (scev_probably_wraps_p): Declaration changed. (convert_step): Declaration removed. (convert_affine_scev, nowrap_type_p, scev_direction): Declare. * gcc.dg/pr27639.c: New test. * gcc.dg/pr26719.c: New test. * gcc.dg/tree-ssa/scev-cast.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr26719.c trunk/gcc/testsuite/gcc.dg/pr27639.c trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-cast.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chrec.c trunk/gcc/tree-flow.h trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-ssa-loop-ivopts.c trunk/gcc/tree-ssa-loop-niter.c trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
[Bug tree-optimization/26719] [4.1/4.2 Regression] Computed (integer) table changes with -O
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-05-24 22:55 --- Subject: Bug 26719 Author: rakdver Date: Wed May 24 22:55:15 2006 New Revision: 114057 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114057 Log: PR tree-optimization/27639 PR tree-optimization/26719 * tree-vrp.c (adjust_range_with_scev): Use scev_direction and adjust call to scev_probably_wraps_p. * tree-ssa-loop-niter.c (compare_trees, convert_step_widening, used_in_pointer_arithmetic_p, convert_step): Removed. (nowrap_type_p): New function. (scev_probably_wraps_p): Rewritten. * tree-scalar-evolution.c (instantiate_parameters_1): Do not call chrec_convert if chrec_convert_aggressive might have been used. * tree-chrec.c (convert_affine_scev, chrec_convert_1, scev_direction): New functions. (chrec_convert): Changed to a wrapper over chrec_convert_1. * tree-ssa-loop-ivopts.c (idx_find_step): Use convert_affine_scev instead of convert_step. * tree-flow.h (scev_probably_wraps_p): Declaration changed. (convert_step): Declaration removed. (convert_affine_scev, nowrap_type_p, scev_direction): Declare. * gcc.dg/pr27639.c: New test. * gcc.dg/pr26719.c: New test. * gcc.dg/tree-ssa/scev-cast.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr26719.c trunk/gcc/testsuite/gcc.dg/pr27639.c trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-cast.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chrec.c trunk/gcc/tree-flow.h trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-ssa-loop-ivopts.c trunk/gcc/tree-ssa-loop-niter.c trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
[Bug bootstrap/27782] New: Bootstrap failure with -msse2 -ftree-vectorize
There is a problem in data dependence analysis that breaks bootstrap with
-ftree-vectorize (or any other flag that causes find_data_references_in_loop to
be called):
stage1/xgcc -Bstage1/ -B/usr/local/i686-pc-linux-gnu/bin/ -c -g -O2 -msse2
-ftree-vectorize -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute
-Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libdecnumber -I../libdecnumber../../gcc/gcc/recog.c -o
recog.o
../../gcc/gcc/recog.c: In function âconstrain_operandsâ:
../../gcc/gcc/recog.c:2273: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
#0 0x0830b9ba in fold_convert (type=0x0, arg=0x402f57f8) at fold-const.c:1991
#1 0x0861768f in chrec_convert_1 (type=0x0, chrec=0x402f57f8,
at_stmt=0x409361b0, use_overflow_semantics=1 '\001') at tree-chrec.c:1268
#2 0x0861738d in chrec_convert (type=0x0, chrec=0x402f57f8,
at_stmt=0x409361b0) at tree-chrec.c:1225
#3 0x0862a6ce in create_data_ref (memref=0x40929d98, stmt=0x409361b0,
is_read=1 '\001') at tree-data-ref.c:1960
#4 0x08632bc8 in find_data_references_in_loop (loop=0x88b5998,
datarefs=0x89e988c) at tree-data-ref.c:4050
#5 0x086338e1 in compute_data_dependences_for_loop (loop=0x88b5998,
compute_self_and_read_read_dependences=0 '\0', datarefs=0x89e988c,
dependence_relations=0x89e9890) at tree-data-ref.c:4189
#6 0x081c38c2 in vect_analyze_data_refs (loop_vinfo=0x89e9868) at
tree-vect-analyze.c:1336
#7 0x081c571d in vect_analyze_loop (loop=0x88b5998) at
tree-vect-analyze.c:1999
#8 0x081c0672 in vectorize_loops (loops=0x88f9f18) at tree-vectorizer.c:2040
#9 0x081ac9fb in tree_vectorize () at tree-ssa-loop.c:193
...
(gdb) fr 3
#3 0x0862a6ce in create_data_ref (memref=0x40929d98, stmt=0x409361b0,
is_read=1 '\001') at tree-data-ref.c:1960
1960 init_cond = chrec_convert (chrec_type (access_fn), init_cond,
stmt);
(gdb) call debug_generic_stmt (access_fn)
scev_not_known;
--
Summary: Bootstrap failure with -msse2 -ftree-vectorize
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rakdver at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27782
[Bug tree-optimization/27779] ICE at tree-data-ref.c:2335 when using -ftree-vectorize
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-29 07:32:51 |2006-05-29 13:39:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27779
[Bug tree-optimization/27779] ICE at tree-data-ref.c:2335 when using -ftree-vectorize
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-05-30 12:33 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01515.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||05/msg01515.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27779
[Bug tree-optimization/27779] ICE at tree-data-ref.c:2335 when using -ftree-vectorize
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-05-30 13:21 --- Subject: Bug 27779 Author: rakdver Date: Tue May 30 13:21:06 2006 New Revision: 114233 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114233 Log: PR tree-optimization/27779 * tree-data-ref.c (analyze_siv_subscript_cst_affine): Use initial_condition instead of CHREC_LEFT. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-data-ref.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27779
[Bug rtl-optimization/27872] Internal compiler error in verify_loop_structure
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-06-05 15:19 --- (In reply to comment #1) > Can you try the patch linked from PR 27735 to see if this fixes this bug also? No, this is unrelated (the ice here is from tree_unroll_loop, never gets to unswitching). -- rakdver at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|27735 | AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-05 15:19:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27872
[Bug rtl-optimization/27872] Internal compiler error in verify_loop_structure
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-06-06 09:02 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00284.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||06/msg00284.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27872
[Bug rtl-optimization/26449] [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invariant motion
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-24 10:46:37 |2006-06-06 09:59:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug rtl-optimization/26449] [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invariant motion
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-06-06 17:19 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00313.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||06/msg00313.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug rtl-optimization/26449] [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invariant motion
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-06-08 08:17 --- Subject: Bug 26449 Author: rakdver Date: Thu Jun 8 08:17:05 2006 New Revision: 114481 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114481 Log: PR rtl-optimization/26449 * loop-invariant.c (move_invariant_reg): Fail if force_operand fails. * gcc.dg/pr26449.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr26449.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug rtl-optimization/27872] Internal compiler error in verify_loop_structure
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-06-08 08:20 --- Subject: Bug 27872 Author: rakdver Date: Thu Jun 8 08:19:50 2006 New Revision: 114482 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114482 Log: PR tree-optimization/27872 * tree-ssa-loop-manip.c (tree_unroll_loop): Set EDGE_IRREDUCIBLE_LOOP flag on the new exit edge of the unrolled loop. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-manip.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27872
[Bug tree-optimization/27809] inefficient gimplification of globals
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-06-13 14:09 --- (In reply to comment #1) > Hmm, it should have produced G.3, G.n, at least I would have thought. > No, we intentionally use the same variable for the lexically identical expressions, see internal_get_tmp_var/lookup_tmp_var. Original intention was to make PRE and other redundancy elimination optimization passes more efficient (this was essential especially for the old SSAPRE pass that used lexical equality of expressions to check for redundancies). These reasons are no longer relevant, but keeping the code saves a significant amount of memory and compile time (I tried removing the code a few months ago, but since it slows down compilation by some 1-2%, I never bothered with posting the patch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27809
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-06-15 11:17 --- Hello, > > http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00241.html suggests we > > still > > have the bug. Can someone confirm this still passes with > > -fno-move-loop-invariants? > > Confirmed. could you please try to simplify the testcase, ideally to separate just the single misscompiled loop? I again failed to find anything wrong using just a crosscompiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug tree-optimization/27331] [4.2 Regression] segfault in fold_convert with -ftree-vectorize
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-06-15 11:31 --- Ccing people responsible for data dependence analysis. I have hacked this over on predcom branch, but I would prefer if someone who understands the code could fix it properly. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added CC||sebastian dot pop at cri dot ||ensmp dot fr, dberlin at gcc ||dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27331
[Bug tree-optimization/27331] [4.2 Regression] segfault in fold_convert with -ftree-vectorize
--- Comment #13 from rakdver at gcc dot gnu dot org 2006-06-20 10:26 --- Subject: Bug 27331 Author: rakdver Date: Tue Jun 20 10:26:45 2006 New Revision: 114810 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114810 Log: PR tree-optimization/27331 * tree-data-ref.c (free_data_ref): New function. (create_data_ref): Fail if the data reference has unknown access function. (free_data_refs): Use free_data_ref. * gcc.dg/pr27331.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr27331.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27331
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-06-05 17:12:46 |2006-06-20 13:37:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
--- Comment #16 from rakdver at gcc dot gnu dot org 2006-06-20 14:26 --- Could you please send the .loop2_invariant dump (-dL) ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug rtl-optimization/28121] [4.2 regression] verify_flow_info failed (wrong amount of branch edges after unconditional jump 2)
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-06-21 14:26 --- On i686-linux, it fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28121
[Bug rtl-optimization/28121] [4.2 regression] verify_flow_info failed (wrong amount of branch edges after unconditional jump 2)
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-06-21 14:37 --- The problem is that the edge from bb 2 has EDGE_EXECUTABLE flag set, which confuses verify_flow_info. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-06-21 11:59:33 |2006-06-21 14:37:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28121
[Bug rtl-optimization/28121] [4.2 regression] verify_flow_info failed (wrong amount of branch edges after unconditional jump 2)
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-06-21 23:15 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01215.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||06/msg01215.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28121
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
--- Comment #19 from rakdver at gcc dot gnu dot org 2006-06-22 10:28 --- The transformations in the invariant motion pass look correct to me, as well as the code immediately after it. Maybe it is a latent bug in some of the later passes, but the code produced for the shift is looong and I was not able to find where things go wrong. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rakdver at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug rtl-optimization/28121] [4.2 regression] verify_flow_info failed (wrong amount of branch edges after unconditional jump 2)
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-06-22 17:54 --- Subject: Bug 28121 Author: rakdver Date: Thu Jun 22 17:54:45 2006 New Revision: 114898 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114898 Log: PR rtl-optimization/28121 * cfgexpand.c (tree_expand_cfg): Clean EDGE_EXECUTABLE flag from the entry edge. * gcc.dg/pr28121.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr28121.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28121
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-07-12 23:13 --- Loop header copying is OK; the result is the one I would expect, it certainly does not make the code worse (unless you are optimizing for code size), and in many cases may make it better. I will have a look at the addressing mode choices. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-14 14:12:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer
--- Comment #13 from rakdver at gcc dot gnu dot org 2006-07-17 11:54 --- (In reply to comment #12) > The test case in comment #11 looks like a classic store motion opportunity to > me. GCC 3.3 performs the store motion, GCC 4.2 r115467 does not. > > Zdenek, I thought tree-ssa-lim should be able to do store motion in loops? Yes, however again, the alias analysis does not tell it that a[0] does not alias a[1]; once that is fixed, tree-ssa-lim should work just fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20643
[Bug tree-optimization/37950] failure in polyhedron benchmark when ftree-parallelize-loops is enabled
--- Comment #2 from rakdver at gcc dot gnu dot org 2008-11-12 04:32 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00506.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg00506.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37950
[Bug tree-optimization/37950] failure in polyhedron benchmark when ftree-parallelize-loops is enabled
--- Comment #3 from rakdver at gcc dot gnu dot org 2008-11-16 04:49 --- Subject: Bug 37950 Author: rakdver Date: Sun Nov 16 04:48:25 2008 New Revision: 141911 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141911 Log: PR tree-optimization/37950 * tree-flow-inline.h (memory_partition): Return NULL when aliases were not computed for the current function. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-flow-inline.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37950
[Bug rtl-optimization/32283] [4.3/4.4 regression] Missed induction variable optimization
--- Comment #22 from rakdver at gcc dot gnu dot org 2008-11-17 03:44 --- (In reply to comment #20) > To add to comment #18, after r128272 GCC for powerpc-linux no longer generates > bdnz for: > ... A patch for this testcase: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00792.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug rtl-optimization/32283] [4.3/4.4 regression] Missed induction variable optimization
--- Comment #23 from rakdver at gcc dot gnu dot org 2008-11-20 08:06 --- Subject: Bug 32283 Author: rakdver Date: Thu Nov 20 08:05:12 2008 New Revision: 142035 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142035 Log: PR rtl-optimization/32283 * tree-ssa-loop-niter.c (scev_probably_wraps_p): Use type of the base of the induction variable to decide whether it may wrap. * tree-ssa-loop-ivopts.c (rewrite_use_compare): Emit the initialization of the bound before the loop. * simplify-rtx.c (simplify_binary_operation_1): Add two simplifications regarding AND. (simplify_plus_minus): Only fail if no simplification is possible. * loop-iv.c (simple_rhs_p): Consider reg + reg and reg << cst simple. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-iv.c trunk/gcc/simplify-rtx.c trunk/gcc/tree-ssa-loop-ivopts.c trunk/gcc/tree-ssa-loop-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-12-10 11:42:50 |2008-12-10 21:31:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #58 from rakdver at gcc dot gnu dot org 2008-12-10 22:55 --- (In reply to comment #56) > Re. comment #52: > > I've pasted the test case in the audit trail here as plain text -- it's pretty > small and it shows the problem nicely. The issue is that with -Os, on all > targets, the line, > > propsRes->lc = prop0; > > is replaced with: > > propsRes->lc = (int) (int) (prop0.24 % 45); // with prop0.24 = propsData[0]; > > so there is no div/mod instruction in the original code, but one appears as a > result of the final value replacement optimization. With -O2 there is also a > div instruction, but I am not sure where it comes from (I suspect loop header > copying, but it's inconsequential for this issue anyway). actually, the div instruction also comes from the final value replacement. We eliminate the loop completely and replace it with the following: D.1286 = prop0 + 211; prop0 = D.1286 % 45; propsRes->pb = [plus_expr] (propsRes->pb + 1) + (int) (D.1286 / 45); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #65 from rakdver at gcc dot gnu dot org 2008-12-12 20:34 --- Subject: Bug 32044 Author: rakdver Date: Fri Dec 12 20:32:47 2008 New Revision: 142719 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142719 Log: PR tree-optimization/32044 * tree-scalar-evolution.h (expression_expensive_p): Declare. * tree-scalar-evolution.c (expression_expensive_p): New function. (scev_const_prop): Avoid introducing expensive expressions. * tree-ssa-loop-ivopts.c (may_eliminate_iv): Ditto. * gcc.dg/pr34027-1.c: Change outcome. * gcc.dg/tree-ssa/pr32044.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr32044.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr34027-1.c trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-scalar-evolution.h trunk/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #66 from rakdver at gcc dot gnu dot org 2008-12-12 20:42 --- (In reply to comment #64) > I agree that the most practical short-term solution is to avoid transforming > the loop into a division. > > However, I'm also interested in what we think the right long-term solution > is. > I'm not convinced that our goal should be to preserve the form used by the > user; rather, I'm inclined to say that our goal should be to (a) recognize the > loop as division, and, (b) generate loops to implement division when > profitable. It's reasonable is to say that the form user by the user > influences the decision about profitability made in (b). Agreed; there are also other parts of tree->rtl expansion that could benefit from using the information about the distribution of the inputs, whether obtained from value profiling, VRP, scev analysis, guesses based on the structure of the program (as in this case), or possibly hints by the user (builtin_expect). I do not have time to work on that now, though (I think it would make a rather nice gsoc project, or a student project in general). -- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rakdver at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug rtl-optimization/38921] [4.3 Regression] NULL access in delay-slot
--- Comment #6 from rakdver at gcc dot gnu dot org 2009-01-21 16:41 --- (In reply to comment #4) > Zdenek, could you please comment on comment #3? > Adding MTP_AFTER_MOVE seems like the right thing to do; after all, even the comments for may_trap_or_fault_p specify that it should behave the same way as may_trap_after_code_motion_p (except for also looking for misaligned memory references). However, I suspect that all the places that use may_trap_after_code_motion_p in fact expect it to have MTP_AFTER_MOVE | MTP_UNALIGNED_MEMS semantics as well. So I would propose to merge may_trap_or_fault_p and may_trap_after_code_motion_p to one function (and replace the checks for MTP_UNALIGNED_MEMS in may_trap_p_1 by MTP_AFTER_MOVE, as they IMHO handle different instances of the same problem -- the code that does not fail at its current location, but may fail elsewhere). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38921
[Bug tree-optimization/40087] [4.3/4.4/4.5 Regression] Number of iterations analysis wrong
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-05-10 09:42:26 |2009-05-10 12:59:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087
[Bug tree-optimization/40087] [4.3/4.4/4.5 Regression] Number of iterations analysis wrong
--- Comment #6 from rakdver at gcc dot gnu dot org 2009-05-15 00:34 --- (In reply to comment #5) > It is number of iteration analysis that gets it wrong (I suppose it might get > confused by the two exits of the loop?). Sort of; # of iterations analysis assumes that pointers never wrap, and uses this assumption to derive a wrong number of iterations for the first exit (which is not taken). We had a similar problem before (PR 25985), but I somehow persuaded myself that this cannot happen with pointers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087
[Bug tree-optimization/40087] [4.3/4.4/4.5 Regression] Number of iterations analysis wrong
--- Comment #9 from rakdver at gcc dot gnu dot org 2009-05-20 00:34 --- Subject: Bug 40087 Author: rakdver Date: Wed May 20 00:33:54 2009 New Revision: 147727 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147727 Log: PR tree-optimization/40087 * tree-ssa-loop-niter.c (number_of_iterations_ne_max, number_of_iterations_ne): Rename never_infinite argument. (number_of_iterations_lt_to_ne, number_of_iterations_lt, number_of_iterations_le): Handle pointer-type ivs when exit_must_be_taken is false. (number_of_iterations_cond): Do not always assume that exit_must_be_taken if the control variable is a pointer. * gcc.dg/tree-ssa/pr40087.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr40087.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087
[Bug tree-optimization/40087] [4.3/4.4 Regression] Number of iterations analysis wrong
--- Comment #12 from rakdver at gcc dot gnu dot org 2009-05-22 20:43 --- Subject: Bug 40087 Author: rakdver Date: Fri May 22 20:43:39 2009 New Revision: 147806 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147806 Log: PR tree-optimization/40087 * tree-ssa-loop-niter.c (number_of_iterations_ne_max, number_of_iterations_ne): Rename never_infinite argument. (number_of_iterations_lt_to_ne, number_of_iterations_lt, number_of_iterations_le): Handle pointer-type ivs when exit_must_be_taken is false. (number_of_iterations_cond): Do not always assume that exit_must_be_taken if the control variable is a pointer. * gcc.dg/tree-ssa/pr40087.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/tree-ssa/pr40087.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-ssa-loop-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087
[Bug middle-end/40259] Unintended code in find_givs_in_stmt_scev (gcc/tree-ssa-loop-ivopts.c)?
--- Comment #2 from rakdver at gcc dot gnu dot org 2009-05-26 17:50 --- (In reply to comment #1) > It looks more like the code in GCC 4.3 is wrong and should use lhs here. > Zdenek? simple_iv should return the same result in both cases, so it should not really matter. Is there some reason why this is reported as a bug, rather than asking in the mailing list? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40259
[Bug middle-end/38729] long time needed in tree canonical iv
--- Comment #5 from rakdver at gcc dot gnu dot org 2009-06-20 17:08 --- (In reply to comment #4) > With MAX_DOMINATORS_TO_WALK zero and find_loop_niter_by_eval completely > disabled > (checking enabled compiler, built with -O0): > > tree iv optimization : 11.12 ( 6%) usr 0.07 ( 5%) sys 12.02 ( 6%) wall > 59123 kB (20%) ggc > > With just find_loop_niter_by_eval disabled: > > tree iv optimization : 10.81 ( 6%) usr 0.05 ( 3%) sys 11.44 ( 6%) wall > 59123 kB (20%) ggc > > so that's it. I assume you were really looking at tree canonical iv counter, not on the tree iv optimization one, otherwise I don't see how you got to this conclusion. > Zdenek - if for one exit we cannot determine the number of executions, > shouldn't we return chrec_dont_know here instead of just examining the > other exits? Why should we? The fact that we cannot determine number of iterations before a particular exit is taken does not tell you anything about the rest of the exits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38729
[Bug regression/40886] [4.3/4.4/4.5 Regression] No loop counter reversal for simple loops anymore
--- Comment #3 from rakdver at gcc dot gnu dot org 2009-08-07 08:44 --- (In reply to comment #1) > The tree optimizers canonicalize the loop to > > : > # i_5 = PHI > # ivtmp.23_1 = PHI > f2 (); > i_3 = i_5 + 1; > ivtmp.23_4 = ivtmp.23_1 - 1; > if (ivtmp.23_4 != 0) > goto ; > else > goto ; > > : > goto ; > > But then IVOPTs chooses i as the induction variable again. This is what I would expect it to do (I am somewhat surprised that 3.3 did something else). Ivopts at the moment do not know that comparing with 0 is more efficient than comparing with any other expression. In all other aspects, i and ivtmp.23 have the same cost, so ivopts prefers to preserve the original induction variable. Altering determine_use_iv_cost_condition to take the cost of the comparison into account should fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40886
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
--- Comment #20 from rakdver at gcc dot gnu dot org 2005-11-04 10:04 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00246.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug tree-optimization/24669] Loop index variable has offset of 1
--- Comment #2 from rakdver at gcc dot gnu dot org 2005-11-04 10:35 ---
There are two reasons we do not produce the code as in the comment #1:
1) This would require reversing the loop, which is currently implemented in
mainline only in old loop optimizer, in a very weak fashion. More powerful
implementation is in killloop branch and should appear in 4.2.
2) Nevertheless, in this particular example we cannot reverse the loop at all
(i.e., the proposed code is incorrect) -- it would cause misscompilations for
example if foo is called as foo(p + 1, p). If p = {1,2,3,4,5}, the original
code sets it to {1,1,1,1,1}, while the new one to {1,1,2,3,4}.
The fact that the index variable is chosen to start with 1 instead of zero is
more interesting. It does not really matter that much, since both
possibilities have exactly the same cost. But the reason is that target
description pretends that the more complicated addressing mode is in fact
cheaper, thus misguiding ivopts to prefer it to the simpler one, if everything
else is equal.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24669
[Bug tree-optimization/24599] [4.0 regression] segv after overflow detection
--- Comment #4 from rakdver at gcc dot gnu dot org 2005-11-04 13:39 --- Nevertheless, the fact that boolean_true_node has overflow flag set is wrong, this should not happen -- shared constants should not be modified. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
[Bug tree-optimization/24599] [4.0 regression] segv after overflow detection
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-04 14:02 ---
This happens in c-typeck.c:build_c_cast:
value = convert (type, value);
/* Ignore any integer overflow caused by the cast. */
if (TREE_CODE (value) == INTEGER_CST)
{
/* If OVALUE had overflow set, then so will VALUE, so it
is safe to overwrite. */
if (CONSTANT_CLASS_P (ovalue))
{
TREE_OVERFLOW (value) = TREE_OVERFLOW (ovalue);
/* Similarly, constant_overflow cannot have become cleared. */
TREE_CONSTANT_OVERFLOW (value) = TREE_CONSTANT_OVERFLOW (ovalue);
}
build_c_cast assumes that convert will not return non-overflowed constant if it
received an overflowed one. This however is not true, since
convert (boolean_type_node, ...) will sometimes return shared
boolean_{true,false}_node constants.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
[Bug rtl-optimization/24762] [killloop-branch] code motion of non-invariant expressions with hard registers.
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-09 22:30 ---
I am testing the following patch:
Index: except.c
===
*** except.c(revision 106702)
--- except.c(working copy)
*** dw2_build_landing_pads (void)
*** 1527,1543
/* If the eh_return data registers are call-saved, then we
won't have considered them clobbered from the call that
!threw. Kill them now. */
for (j = 0; ; ++j)
{
unsigned r = EH_RETURN_DATA_REGNO (j);
if (r == INVALID_REGNUM)
break;
! if (! call_used_regs[r])
! {
! emit_insn (gen_rtx_CLOBBER (VOIDmode, gen_rtx_REG (Pmode, r)));
! clobbers_hard_regs = true;
! }
}
if (clobbers_hard_regs)
--- 1527,1544
/* If the eh_return data registers are call-saved, then we
won't have considered them clobbered from the call that
!threw. But we need to clobber all hard registers, since
!df.c assumes that call clobbers are not definitions
!(normally it is invalid to use call-clobbered register
!after the call). */
for (j = 0; ; ++j)
{
unsigned r = EH_RETURN_DATA_REGNO (j);
if (r == INVALID_REGNUM)
break;
!
! emit_insn (gen_rtx_CLOBBER (VOIDmode, gen_rtx_REG (Pmode, r)));
! clobbers_hard_regs = true;
}
if (clobbers_hard_regs)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24762
[Bug rtl-optimization/24760] -d option changes generated code
--- Comment #6 from rakdver at gcc dot gnu dot org 2005-11-09 22:36 --- Yes, this is indeed the case. I am testing the fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24760
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
--- Comment #23 from rakdver at gcc dot gnu dot org 2005-11-11 13:38 --- Subject: Bug 22509 Author: rakdver Date: Fri Nov 11 13:38:07 2005 New Revision: 106783 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106783 Log: PR rtl-optimization/22509 * local-alloc.c (memref_used_between_p): Check whether a function call could not reference the memref. Modified: trunk/gcc/ChangeLog trunk/gcc/local-alloc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #3 from rakdver at gcc dot gnu dot org 2005-11-13 10:02 --- This is easy to implement; the question is whether we really want to waste compile time to handle this type of examples that do not seem very likely to appear in practice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug rtl-optimization/24497] [3.4/4.0/4.1 Regression] internal compiler error: in apply_opt_in_copies, at loop-unroll.c:2122
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24497
[Bug tree-optimization/23821] [4.0/4.1 Regression] DOM and VRP creating harder to optimize code
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-14 09:16 --- The testcase comes from gcc testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug rtl-optimization/24762] [killloop-branch] code motion of non-invariant expressions with hard registers.
--- Comment #15 from rakdver at gcc dot gnu dot org 2005-11-15 14:27 --- Subject: Bug 24762 Author: rakdver Date: Tue Nov 15 14:27:48 2005 New Revision: 107017 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107017 Log: PR rtl-optimization/24762 * except.c (dw2_build_landing_pads): Always emit clobbers for eh registers. Modified: branches/killloop-branch/gcc/ChangeLog.killloop branches/killloop-branch/gcc/except.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24762
[Bug fortran/24793] [4.1 Regression] ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-16 12:13 --- A patch is here (only the ivopts and get_tmr_operands parts). I am retesting it now. http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01608.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
[Bug fortran/24793] [4.1 Regression] ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
--- Comment #6 from rakdver at gcc dot gnu dot org 2005-11-17 12:33 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01283.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg01283.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Comment #34 from rakdver at gcc dot gnu dot org 2005-11-17 13:35 --- It behaves somewhat erratically on SPEC2000 (it increases the overall score, but there are some significant regressions). And, it also causes us to produce worse code for this testcase at the moment, due to a missunderstanding between ivopts and fold; expression (unsigned char) (signed char) (int) (ptr + 1B) - (unsigned char) ptr is produced, and it is not folded to 1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Comment #35 from rakdver at gcc dot gnu dot org 2005-11-17 15:09
---
Created an attachment (id=10263)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10263&action=view)
Patch
After some playing with fold, I arrived to the following patch, that almost
works. With the patch, the code for the loop is
:;
MEM[base: ptr]{*ptr} = cleanse_ctr;
ptr = ptr + 1B;
cleanse_ctr = (unsigned char) (((signed char) ptr & 15) + (signed char)
cleanse_ctr + 17);
len = len - 1;
if (len != 0) goto ; else goto ;
Which seems just fine. The assembler is
.L3:
movb(%edi), %al
movb%al, (%ecx)
incl%ecx
movb%cl, %al
andl$15, %eax
movb(%edi), %dl
addl$17, %edx
addl%edx, %eax
movb%al, (%edi)
decl%esi
jne .L3
Which also seems OK to me. However, the "ugly" version we produce without the
patch:
.L4:
movb(%edi), %al
movb%al, (%ecx)
incl%ecx
movb-16(%ebp), %al
addl%esi, %eax
andl$15, %eax
movb(%edi), %dl
addl$17, %edx
addl%edx, %eax
movb%al, (%edi)
incl%esi
cmpl12(%ebp), %esi
jne .L4
Is faster by 30%, from reasons I just don't understand :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
