This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [CFG] Unswitching cleanup
Hello.
> > This patch cleans up the code concerning loop unswitching a lot, removing most
> > of the dark magic. It also allows us to really remove the loop when we peel it
> > completely (till now we were just leaving it in place, hoping that some
> > following optimization pass will get rid of it).
>
> Thanks. I will take a look at it shortly. One thing I was thinking about
> is that we may make the unswitching independent on the midrtl just
> by using canonicalize_comparison on the condition we get from condtiional
> and re-emiting the jump again based on the comparison. I will take a look
> how dificult it is to integrate into current design.
>
> > *************** void verify_loop_structure (loops, flags
> > *** 1140,1145 ****
> > --- 1201,1209 ----
> > for (i = 1; i < loops->num; i++)
> > {
> > loop = loops->parray[i];
> > + if (!loop)
> > + continue;
> > +
>
> This looks fine. I am afraid there is a lot more places we will have
> to care NULL pointers tought.
Not on relevant places (i.e. where we could have holes in this array); I'm
almost sure I've found all the places in loop optimizer where we use it,
and nowhere else is the loop structure manipulated.
> > !
> > ! /* Find border hexes. */
> What do you mean by the border hexes?
Hexes on border of the removed area (i.e. such that they have at least one
removed entry edge).
> > *************** count_loop_iterations (desc, niter, rnit
> > *** 418,427 ****
> > unsigned HOST_WIDE_INT abs_diff = 0;
> > enum rtx_code cond = desc->cond;
> >
> > if (desc->grow)
> > {
> > /* Bypass nonsential tests. */
> > ! if (cond == GE || cond == GT || cond == GEU || cond == GTU)
> > return false;
> > if (rniter)
> > {
> > --- 432,449 ----
> > unsigned HOST_WIDE_INT abs_diff = 0;
> > enum rtx_code cond = desc->cond;
> >
> > + /* Ensure that we always handle the condition to stay inside loop. */
> > + if (desc->neg)
> > + {
> > + cond = reverse_condition (cond);
> > + if (cond == UNKNOWN)
> > + return false;
> > + }
> > +
>
> Hmm, how can the UNKNOWNS get here? They can happen only for floats
> and we hsould rule them out earlier. I guess I will just add the
> test into simple_loop to verify that induction variable is integral.
They cannot; I didn't look inside reverse_condition, I just read its
description :-)
Zdenek