On Thu, Oct 17, 2013 at 11:26:56AM +0200, Richard Biener wrote:
> On Wed, 16 Oct 2013, pins...@gmail.com wrote:
>
> >
> > > On Oct 15, 2013, at 5:32 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> > > Especially on i?86/x86_64 if-conversion pass seems to be often
> > > a pessimization, but the vectorization relies on it and without it we
> > > can't
> > > vectorize a lot of the loops.
> >
> > I think on many other targets it actually helps. I know for one it
> > helps on octeon even though octeon has no vector instructions. I think
> > it helps most arm targets too.
>
> The main issue is that it has no cost model - the only cost model
> being that it can successfully if-convert all conditional code in
> a loop, resulting in a single-BB loop. So it is clearly vectorization
> targeted.
>
> It's infrastructure may be useful to do a more sensible if-conversion
> on GIMPLE level on scalar code.
>
> Of course even the infrastructure needs some TLC (and some better
> generic machinery of keeping track and simplifying of a predicate
> combination).
Yeah, or, if tree if-conversion is a net win for some port even when not
vectorizing, supposedly such a port should at least until the above is
implemented just enable flag_tree_loop_if_convert by default, at least at
some -O* levels. Of course the question is why would it be beneficial only
in inner loops and not elsewhere (other loops, or stright line code),
and when it is desirable and when not (for vectorization we of course try
hard to if-convert the whole loop, because otherwise we are not able to
vectorize it, but otherwise, is it beneficial just for a couple of
conditionalized stmts at most, or is it fine to conditionalize say 1000
arithmetic statements?).
Jakub
