A prototype loop reverser for the scalarizer

[Steven Bosscher]

On 10/8/06, Daniel Berlin <dberlin@dberlin.org> wrote:
> > This is total bollocks unless you can optimize away the additional
> > temporary and the copy-in&copy-out operations. I don't see _that_
> > happening any time soon.
> It will *never* happen unless people stop reimplementing things where
> it may be temporarily easiest for them, and instead do it where it
> will bring the most benefit, even if it's harder.

Considering it's a 30 line patch I don't see any problem having it in
the front end _and_ the middle end (that is, if the middle-end
implementation is finished).

Right now, to do this in the middle end, for, ehm, almost no
interesting cases that the simple implementation already catches,
means:
- teach the middle-end somehow that array descriptor fields can't be
aliased - but we don't have any way to express that right now and
adding it is not easy without help; and
- teach the middle-end about temporaries that are allocated, so that
it knows how to optimize away the copy-in&copy-out operations and the
memory allocations for the temporaries.

Seems like an awful lot of work to me, with almost no benefit.


> > Plus, there is much more detailed information readily available in the
> > front end than what the middle-end will be able to derive.
> >
> And to avoid the situation we have in RTL, where we've lost all the
> useful info, you should, you know, pass that information to the middle
> end, so it can do this.

Please elaborate, because I hear a plan... no?

> Going off and implementing a highly optimizing frontend may help you
> in the short term, but it's an incredibly wrong headed strategy in the
> long term.

As I said: 30 lines or so.  Hardly seems "highly optimizing" to me.
Just, handling a common case early on.  Besides, this is
scalarization, which is going to be in the front end and requires
dependence analysis no matter what.  Doing it well for common cases is
what I _expect_ from the front end here.

> But hey, why should we introduce long term thinking into GCC now, when
> you can do something locally good with a design that won't work for
> you in 5 years when the world changes.

Oh, look!  You've re-invented sarcasm!
Fortunately, in this case the world won't change so much.

> > So it's only right to add these transformations in the Fortran front end.
>
> Again, I disagree.

Let's agree to disagree then.  I hope Paul does finish this patch
despite the way you feel about the idea.

Gr.
Steven