On 05/30/2016 09:26 AM, Jan Hubicka wrote:
Hi,
this is version of patch I intend to commit after re-testing at x86_64-linux
with loop peeling enabled at -O3.
It drops -fpeel-all-loops, add logic to not peel loops multiple times
and fix profile updating.
Bootstrapped/regtested x86_64-linux
Honz
Hi,
this is version of patch I intend to commit after re-testing at x86_64-linux
with loop peeling enabled at -O3.
It drops -fpeel-all-loops, add logic to not peel loops multiple times
and fix profile updating.
Bootstrapped/regtested x86_64-linux
Honza
* doc/invoke.texi (-fpeel-loops,-O
>
> Sounds good.
>
> The patch is ok if you omit the new flag for now.
Ok, I will omit that flag for now. Thanks!
Honza
>
> Thanks,
> Richard.
On Mon, 30 May 2016, Jan Hubicka wrote:
> > On Sat, 28 May 2016, Jan Hubicka wrote:
> >
> > > Hello,
> > > thanks for feedback. I updated the patch and also noticed that
> > > -fpeel-all-loops gives up when
> > > upper bound is known but it is large and when the max-peel-insns is too
> > > smal
> On Sat, 28 May 2016, Jan Hubicka wrote:
>
> > Hello,
> > thanks for feedback. I updated the patch and also noticed that
> > -fpeel-all-loops gives up when
> > upper bound is known but it is large and when the max-peel-insns is too
> > small to permit
> > peeling max-peel-times. This patch als
On Sat, 28 May 2016, Jan Hubicka wrote:
> Hello,
> thanks for feedback. I updated the patch and also noticed that
> -fpeel-all-loops gives up when
> upper bound is known but it is large and when the max-peel-insns is too small
> to permit
> peeling max-peel-times. This patch also updates pr617
Hello,
thanks for feedback. I updated the patch and also noticed that -fpeel-all-loops
gives up when
upper bound is known but it is large and when the max-peel-insns is too small
to permit
peeling max-peel-times. This patch also updates pr61743-2.c which are now
peeled before
we manage to prop
On 05/27/2016 07:19 AM, Jan Hubicka wrote:
[snip]
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 236815)
+++ doc/invoke.texi (working copy)
@@ -8661,10 +8661,17 @@ the loop is entered. This usually makes
@item
> > @@ -0,0 +1,11 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O3 -fdump-tree-loop-ivcanon" } */
>
> This should probably be -fdump-tree-ivcanon-details.
Yep, I updated the testcaes in my tree.
>
> > +struct foo {int b; int a[3];} foo;
> > +void add(struct foo *a,int l)
> > +{
> > + i
On Fri, May 27, 2016 at 03:19:29PM +0200, Jan Hubicka wrote:
> Hi,
> this patch enabled -fpeel-loops by default at -O3 and makes it to use likely
> upper bound estimates. The patch also adds -fpeel-all-loops flag that is
> symmetric to -funroll-all-loops. Long time ago we used to interpret
> -fpe
Hi,
this patch enabled -fpeel-loops by default at -O3 and makes it to use likely
upper bound estimates. The patch also adds -fpeel-all-loops flag that is
symmetric to -funroll-all-loops. Long time ago we used to interpret
-fpeel-loops this way and blindly peel every loop but this behaviour got lo
11 matches
Mail list logo