This is the mail archive of the mailing list for the GNU Fortran project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A prototype loop reverser for the scalarizer

On 10/8/06, Daniel Berlin <> 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,
- 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]