On Thu, 24 Oct 2013, Tobias Burnus wrote:
> Richard Biener wrote:
> > Please instead amend tree-cfg.c:execute_build_cfg and do after
> > loop_optimizer_init sth like
> > [...]
> > possibly doing after it
> > FOR_EACH_BB (bb)
> > [...]
> > +DEFTREECODE (ANNOTATE_EXPR, "annotate_expr", tcc_expression, 1)
> >
> > FIXME? Btw, not using a tree operand here is somewhat of a premature
> > optimization I think ...
>
> I have now moved the code to a new function in tree-cfg.c. As it was not
> completely clear to me after the IRC discussion whether it is sufficient to
> assume that loop->latch == NULL won't occur (and rely on the assert in
> internal_fn), I created a version with FOR_EACH_BB and without. (see #if 0
> code in tree-cfg.c).
>
> For both versions, I did a true all-language bootstrap+ regtesting on
> x86-64-gnu-linux.
>
> Additionally, the ID is now stored in an INTEGER_CST and I also documented
> ANNOTATE_EXPR in generic.texi.
>
> OK? Or are there more comments?
Looks good to me now ...
> Tobias
>
> PS: Before committal, I will remove the #if 0 code - or enable it, as
> preferred.
... I think it's "easy" to trigger.
entry:
#pragma GCC ivdep
for (i = 0; i < n; ++i) {
a[i] = b[i] + c[i];
if (i == 5)
goto entry;
a[i] = a[i] + 1;
}
or by using setjmp/longjmp and thus having some abnormal edges
into a function call inside a loop.
The whole point is that execute_build_cfg passes AVOID_CFG_MODIFICATIONS
to loop_optimizer_init and thus it won't disambiguate loops with
multiple latches. We could eventually change that and pass
LOOPS_HAVE_SIMPLE_LATCHES, but I'm not sure if that works well enough
alone (it's not really tested besides of in combination LOOPS_NORMAL).
Richard.
