Hi Jeff,
On Thu, May 16, 2019 at 12:41:16PM -0600, Jeff Law wrote:
> For architectures like PPC, we probably don't want to use the loop count
> for anything else as it's likely expensive to get data in/out of the the
> loop count register.
That is part of it. Another part is that it costs extra code, negating
one of the advantages of using these instructions. And a third reason
we do not want this is that on some implementations you have to load the
count register early enough to get the loop predicted correctly.
> So at least part of the problem is cost modeling of this. It's all
> pretty low level, so not really a good match for the goals of gimple.
> But we may ultimately have no choice here but to be pragmatic like we've
> done with stuff like vector widths and allow some target properties to
> bleed in.
*All* of ivopts is low level in this sense: *all* of it is about finding
out what IVs to use such that it is lowest cost on the target.
Other than costs it doesn't use many target attributes. For doloop it
would also ask the target whether some loop can be a doloop at all. So
everything it does is quite high level still, but it *does* have to know
about some very machine-specific things.
Maybe two hooks for that: one, taking a struct loop, to decide if that
loop should be considered for a doloop at all; and another taking a
gimple statement, and returning whether that statement prevents the
loop it is in from being a doloop. That way we do not have to pass
a lot of gimple data and work to the backends. Most can just look at
some of the simple loop properties ("is this an inner loop?"), and
allow all statements or just disallow some particular types.
> > Otherwise I understand that IVOPTs doesn't properly cost
> > the doloop IV update and conditional branch. That's clearly
> > something we should fix (maybe even indepenently on other
> > changes).
> It feels independent to me.
It cannot cost things properly if nothing has yet decided whether some
loop could (or should) be a doloop :-)
Segher
