This is the mail archive of the fortran@gcc.gnu.org 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


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

Uh, except for all the other languages that have the same problem with needing to remove temporary allocations and optimize copy-in/out sites, like C++, C, objc, and Java.

As I told you on IRC, IBM used to do this stuff all in their Fortran
front end, and then discovered they wanted it for all their other
languages too.
As did SGI (which re engineered an entire IPA Loop Nest Optimizer to
avoid doing it in the Fortran FE), and AFAIK, Intel.




> > 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?

It's actually pretty clear you don't want to hear it.



> 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.

Please tell me you are joking.



> > 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.

Okeydokey. Really, you guys are free to develop it all how you see fit. Yes, sometimes it's much harder work doing it where everyone can benefit. I could have implemented loop interchange for SWIM in the Fortran frontend in probably 60 lines of code. Instead, I took 3 months and did it where C++ and C benefit as well (and contrary to what some may believe, i've had reports from some very happy people with C and C++ apps).

It is of course, up to whoever implements it to implement it where
they want, as long as there are people willing to approve it.  I can
only offer an opinion as to where I would do it, and why

Gr. Steven



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