Message ID | d51b1ef8-69c1-0f36-9a77-2aa5ae56c38b@suse.cz |
---|---|
State | New |
Headers | show |
Series | Properly sum costs in tree-vect-loop.c (PR tree-optimization/90973). | expand |
On Tue, 2019-06-25 at 10:16 +0200, Martin Liška wrote: > Hi. > > That's a thinko that's pre-approved by Richi. > > Patch can bootstrap on x86_64-linux-gnu and survives regression > tests. > > Thanks, > Martin > > gcc/ChangeLog: > > 2019-06-24 Martin Liska <mliska@suse.cz> > > PR tree-optimization/90973 > * tree-vect-loop.c (vect_get_known_peeling_cost): Sum retval > of prologue and epilogue. > --- > gcc/tree-vect-loop.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c > index d3facf67bf9..489bee65397 100644 > --- a/gcc/tree-vect-loop.c > +++ b/gcc/tree-vect-loop.c > @@ -3405,8 +3405,8 @@ vect_get_known_peeling_cost (loop_vec_info loop_vinfo, int peel_iters_prologue, > iterations are unknown, count a taken branch per peeled loop. */ > retval = record_stmt_cost (prologue_cost_vec, 1, cond_branch_taken, > NULL, 0, vect_prologue); > - retval = record_stmt_cost (prologue_cost_vec, 1, cond_branch_taken, > - NULL, 0, vect_epilogue); > + retval += record_stmt_cost (prologue_cost_vec, 1, cond_branch_taken, ^^^^^^^^^^^^^^^^^^ Should this be epilogue_cost_vec? > + NULL, 0, vect_epilogue); (caveat: I'm purely going by symmetry here)
On Tue, Jun 25, 2019 at 10:50 AM David Malcolm <dmalcolm@redhat.com> wrote: > > On Tue, 2019-06-25 at 10:16 +0200, Martin Liška wrote: > > Hi. > > > > That's a thinko that's pre-approved by Richi. > > > > Patch can bootstrap on x86_64-linux-gnu and survives regression > > tests. > > > > Thanks, > > Martin > > > > gcc/ChangeLog: > > > > 2019-06-24 Martin Liska <mliska@suse.cz> > > > > PR tree-optimization/90973 > > * tree-vect-loop.c (vect_get_known_peeling_cost): Sum retval > > of prologue and epilogue. > > --- > > gcc/tree-vect-loop.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c > > index d3facf67bf9..489bee65397 100644 > > --- a/gcc/tree-vect-loop.c > > +++ b/gcc/tree-vect-loop.c > > @@ -3405,8 +3405,8 @@ vect_get_known_peeling_cost (loop_vec_info loop_vinfo, int peel_iters_prologue, > > iterations are unknown, count a taken branch per peeled loop. */ > > retval = record_stmt_cost (prologue_cost_vec, 1, cond_branch_taken, > > NULL, 0, vect_prologue); > > - retval = record_stmt_cost (prologue_cost_vec, 1, cond_branch_taken, > > - NULL, 0, vect_epilogue); > > + retval += record_stmt_cost (prologue_cost_vec, 1, cond_branch_taken, > ^^^^^^^^^^^^^^^^^^ > Should this be epilogue_cost_vec? I think so. > > + NULL, 0, vect_epilogue); > > (caveat: I'm purely going by symmetry here)
On 6/25/19 4:18 PM, Richard Biener wrote: > On Tue, Jun 25, 2019 at 10:50 AM David Malcolm <dmalcolm@redhat.com> wrote: >> >> On Tue, 2019-06-25 at 10:16 +0200, Martin Liška wrote: >>> Hi. >>> >>> That's a thinko that's pre-approved by Richi. >>> >>> Patch can bootstrap on x86_64-linux-gnu and survives regression >>> tests. >>> >>> Thanks, >>> Martin >>> >>> gcc/ChangeLog: >>> >>> 2019-06-24 Martin Liska <mliska@suse.cz> >>> >>> PR tree-optimization/90973 >>> * tree-vect-loop.c (vect_get_known_peeling_cost): Sum retval >>> of prologue and epilogue. >>> --- >>> gcc/tree-vect-loop.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >> >>> diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c >>> index d3facf67bf9..489bee65397 100644 >>> --- a/gcc/tree-vect-loop.c >>> +++ b/gcc/tree-vect-loop.c >>> @@ -3405,8 +3405,8 @@ vect_get_known_peeling_cost (loop_vec_info loop_vinfo, int peel_iters_prologue, >>> iterations are unknown, count a taken branch per peeled loop. */ >>> retval = record_stmt_cost (prologue_cost_vec, 1, cond_branch_taken, >>> NULL, 0, vect_prologue); >>> - retval = record_stmt_cost (prologue_cost_vec, 1, cond_branch_taken, >>> - NULL, 0, vect_epilogue); >>> + retval += record_stmt_cost (prologue_cost_vec, 1, cond_branch_taken, >> ^^^^^^^^^^^^^^^^^^ >> Should this be epilogue_cost_vec? > > I think so. > >>> + NULL, 0, vect_epilogue); >> >> (caveat: I'm purely going by symmetry here) I've got a patch that I've been testing. I'll install it if it survives regression tests. Thanks, Martin
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c index d3facf67bf9..489bee65397 100644 --- a/gcc/tree-vect-loop.c +++ b/gcc/tree-vect-loop.c @@ -3405,8 +3405,8 @@ vect_get_known_peeling_cost (loop_vec_info loop_vinfo, int peel_iters_prologue, iterations are unknown, count a taken branch per peeled loop. */ retval = record_stmt_cost (prologue_cost_vec, 1, cond_branch_taken, NULL, 0, vect_prologue); - retval = record_stmt_cost (prologue_cost_vec, 1, cond_branch_taken, - NULL, 0, vect_epilogue); + retval += record_stmt_cost (prologue_cost_vec, 1, cond_branch_taken, + NULL, 0, vect_epilogue); } else {