This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug testsuite/59494] [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized "vect_[^\\n]*\\+ " 13
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 13 Jan 2014 11:18:06 +0000
- Subject: [Bug testsuite/59494] [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized "vect_[^\\n]*\\+ " 13
- Auto-submitted: auto-generated
- References: <bug-59494-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59494
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> Alternatively we should just remove that scan-tree-dump-times from the test
> altogether, counting additions where either lhs or rhs1 of addition has
> vect_ in name is quite flawed, we have lots of other vector additions that
> just use anonymous SSA_NAMEs without any name (_114 etc.), but still have
> vector types.
>
> Counting addps etc. insns doesn't work though, there are 23 before and after
> the r156043 change.
>
> Richard, what is your preference here?
Well,
! we want to check that predictive commoning did something on the
! vectorized loop, which means we have to have exactly 13 vector
! additions.
which means to look at the pcom dump (and maybe enhance it). On
x86_64 the interesting line in -details is
"Unrolling 2 times."
dumped from
/* Execute the predictive commoning transformations, and possibly unroll the
loop. */
if (unroll)
{
struct epcc_data dta;
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "Unrolling %u times.\n", unroll_factor);
...
}
else
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file,
"Executing predictive commoning without unrolling.\n");
execute_pred_commoning (loop, chains, tmp_vars);
}
a common "Executing predictive commoning on loop %d" would be possibly
useful. Eventually with "on %d chains" as well. All of this even without
-details and within the opt-dumping framework (MSG_OPTIMIZED_LOCATIONS).