> > We can also patch in __builtin_unreachable but that will make bugs with
> > out overflows/ out of bound accesses hard in loops to debug at -O levels
> > (as seen by do-1.f90 testcase and the new PR with integer overflow), so
> > perhaps we could do that at -Ofast or only or with
> > -funsaf
On Thu, 25 Oct 2012, Jan Hubicka wrote:
> > On Thu, 25 Oct 2012, Jan Hubicka wrote:
> >
> > > > > * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Add
> > > > > edge_to_cancel
> > > > > parameter and use it to estimate code optimized out in the
> > > > > final iteration.
> >
> On Thu, 25 Oct 2012, Jan Hubicka wrote:
>
> > > > * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Add
> > > > edge_to_cancel
> > > > parameter and use it to estimate code optimized out in the
> > > > final iteration.
> > > > (loop_edge_to_cancel): New function.
> >
On Thu, 25 Oct 2012, Jan Hubicka wrote:
> > > * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Add
> > > edge_to_cancel
> > > parameter and use it to estimate code optimized out in the final
> > > iteration.
> > > (loop_edge_to_cancel): New function.
> > > (tr
> > * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Add
> > edge_to_cancel
> > parameter and use it to estimate code optimized out in the final
> > iteration.
> > (loop_edge_to_cancel): New function.
> > (try_unroll_loop_completely): New IRRED_IVALIDATED param
On Tue, Oct 16, 2012 at 10:32 AM, Jan Hubicka wrote:
> Hi,
> here is third revised version of the complette unroling changes. While
> working
> on the RTL variant I noticed PR54937 and the fact that I was overly aggressive
> on forcing single exit of the last iteration to be taken, because loop
On Tue, 16 Oct 2012, Jan Hubicka wrote:
> Hi,
> here is third revised version of the complette unroling changes. While
> working
> on the RTL variant I noticed PR54937 and the fact that I was overly aggressive
> on forcing single exit of the last iteration to be taken, because loop may
> termin
Hi,
here is third revised version of the complette unroling changes. While working
on the RTL variant I noticed PR54937 and the fact that I was overly aggressive
on forcing single exit of the last iteration to be taken, because loop may
terminate
otherwise (by EH or by exitting the program). Sam
Hi,
here is an updated patch. The idea of splitting loopback edge did not fly. We
then remove the edge in cfgcleanup prior demolyshing the loop and we loose
track on what basic blocks needs updating because we no longer can get the loop
body.
As a good news however I do not need the changed loop
> On Fri, 12 Oct 2012, Jan Hubicka wrote:
>
> > > > * f95-lang.c (gfc_init_builtin_functions): Build
> > > > __builtin_unreachable.
> > >
> > > I wonder if other languages need similar adjustment?
> >
> > I also wondered ;) Only Fortran triggered, I will take a look.
> > >
> > > + /*
> > > * f95-lang.c (gfc_init_builtin_functions): Build __builtin_unreachable.
> >
> > I wonder if other languages need similar adjustment?
>
> I also wondered ;) Only Fortran triggered, I will take a look.
> >
> > + /* Now destroy the loop. First try to do so by cancelling the
> > + patc
On Fri, 12 Oct 2012, Jan Hubicka wrote:
> > > * f95-lang.c (gfc_init_builtin_functions): Build __builtin_unreachable.
> >
> > I wonder if other languages need similar adjustment?
>
> I also wondered ;) Only Fortran triggered, I will take a look.
> >
> > + /* Now destroy the loop. First try
> > * f95-lang.c (gfc_init_builtin_functions): Build __builtin_unreachable.
>
> I wonder if other languages need similar adjustment?
I also wondered ;) Only Fortran triggered, I will take a look.
>
> + /* Now destroy the loop. First try to do so by cancelling the
> + patch from exit co
On Thu, 11 Oct 2012, Jan Hubicka wrote:
> Hi,
> while looking into RTL loop peeling micopmilation I found that we now do a
> lot of
> RTL loop peeling for loops of the form
>
> int a[2];
> test(int c)
> {
> int i;
> for (i=0;i a[i]=5;
> }
> this is because tree-ssa-loop-niter is able to
14 matches
Mail list logo
