chased@rbbb.Eng.Sun.COM (David Chase) (03/12/91)
In article <1991Mar6.213417.25734@news.arc.nasa.gov> lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes: >I would be curious to know if any of the IL's for vectorizing compilers, >commercial or not, have been published. ... I believe that there is some technical report you can get from Rice, probably 10 years old by now, that describes the abstract syntax tree used for their vectorizing Fortran translator. There's not too much to it, really -- it's just an abstract syntax tree (not a parse tree, thank you), and you work from there. Many of the transformations are easily expressed at the (extended) source level. Note that the tree is often substantially decorated with information. New vectorizers may be written in a different manner, but for Fortran alone it is probably easiest to work at a high level. >It seems that vectorization is generally viewed as a front-end, >language-dependent, process, unlike what you might expect. Consider a couple of influences: (1) When the research started, Fortran was where it was at. (2) It is far easier to vectorize Fortran than it is to vectorize C because of the aliasing rules w.r.t. subroutine arguments. Fortran's got them, C doesn't. You can add pragmas or compiler flags to enable them for C, but then you have to deal with all the old code for which those changes might be incorrect. Do Fortran, and you avoid the hassle. Plenty of input data for your compiler, too -- if it was C, you'd have to be more careful. Do Fortran, you avoid the hassle. [Note -- this has nothing do with whether or not C should have the rules, or if C compilers should support them. The lack of these rules made targeting C difficult, and there was ample demand for Fortran. Thus, no need to pay any attention to C.] (3) When the research started, it wasn't clear whether or not vectorization could be done quickly enough to justify doing it "all the time" in the compiler. A source-to-source translation followed by tweaking and debugging of the output source was what was imagined. (4) Some users of vectorizing compilers wanted to look at the output, to see if they could further improve the code. This is easier at the source level. I hope this gives some historical context to why things are the way that the are. David Chase Sun