Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!titan!preston
From: preston@titan.rice.edu (Preston Briggs)
Newsgroups: comp.lang.misc
Subject: Re: interprocedural analysis
Message-ID: <6597@brazos.Rice.edu>
Date: 12 Apr 90 06:04:31 GMT
References: <6563@brazos.Rice.edu> <14337@lambda.UUCP>
Sender: root@rice.edu
Organization: Rice University, Houston
Lines: 56

In article <14337@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>From article <6563@brazos.Rice.edu>, by preston@titan.rice.edu (Preston Briggs):

>> A big consequence is that the system needs access to all the source.

>That could be the major problem.  Vendors are not usually keen to give out
>source code.  They are perfectly willing to give out relocatable libraries
>but not source.  This means that your steps 2&3 need to be done by the
>end user.  How does this differ from having the loader do it?

Actually, Floating Point Systems has taken the very polite step of
releasing all the source to all their math libraries, I believe for
free and with minimal liscencing.
Additionally, there's all the linpack and blas source avaliable.
Perhaps it's not such a big problem.

At any rate,
I can imagine a few ad-hoc solutions.  Vendors could supply object libraries
that were compiled using no interprocedural info.  If they included the
necessary summary info for each routine, then step 2 (the interprocedural
analysis) and step 3 (the compilations) could proceed normally and with
respectable levels of optimization.

With no aliasing, this is better than current practise.
Adiitionally, the analysis could detect aliasing violations in
the source.

If we care to allow aliasing, then they might provide 2 versions,
one assuming no aliasing and one assuming the worst.  Then step 2
could determine which version needs to be linked in.

A more practical solution (perhaps) would be to provide the libraries
in an intermediate form, rather than source or object.
Then we could use step 3 to finish the compilation,
using the interprocedural info to produce a properly optimized version.

Regarding the load time question,
I barely remember the original posting.  It suggested
this was a scheme that Tera was planning to use.  I expect the
rumor is a distortion, and the likely truth is that Tera will use
a scheme similar to what I outlined in my earlier posting.
Why?  Some of their compiler people contributed to this work
while at Rice and I would expect them to continue in the same vein.
Why?  They want to build fast machines and good optimization is important
to them.  Naturally, being the vendor, they won't have troubles with
source restrictions!

Cray's compilers already produce a lot of the required information
for other reasons.  It's not that much work to take the extra steps.
Convex is supposed to be building such a compiler.
Push on your vendor; the necessary theory has been provided
and examples have been built.  It's time to see some better
compilers:-)
--
Preston Briggs				looking for the great leap forward
preston@titan.rice.edu