J3/98-231 To: J3 From: khb Subject: Interline Optimization Reference:97-263 I am unsure of the status of 97-263. If we think it passed as specification, we should consider progressing the work. Some highlights from that paper: It has been previously noted that all Fortran compilers perform interline optimizations that are forbidden by the standard. Users demand and vendors provide such behavior. ...The 80-bit registers vs. 64-bit data types of the x86 architecture also exemplify the problem. Fortran 90 Interpretation Number 1 illustrates the confusion caused in the minds of users. ... After reflection, we believe that the optimizations permitted within a statement should apply to programs. In accord with previous committee decisions there will be a "traditional" model of execution and a processor dependent (for example, a compiler option) method of changing between modes on a compilation unit basis. This does not preclude a finer-grained methodology later. We looked at section 2.3.4, all of section 7, and section 8. Section 8 is not germane. Section 7 defines what is permitted within a statement. Section 7.1, page 87, lines 14 and 15 tell what an operand is. For increased clarity, we suggest that the Editor consider changing these two lines from: An operand is either a scalar or an array. An operation is either intrinsic (7.2) or defined (7.3). More complicated expressions can be formed using operand which are themselves expressions. to: An operand is either a scalar, an array, or an expression. An operation is either intrinsic (7.2) or defined (7.3). Section 2.3.4 describes program behavior in terms of execution of statements one at a time. We feel that an additional alternate description is needed. Previously, the committee has rejected the notion of "per line" optimization control. However, this sort of facility is of interest to folks doing careful numerical programming. Oddly enough, as things stand, C provides a careful user with more precise control than Fortran. A "per line" type of control could be provided via a "null" block structure. Inside such a block, transformations could be freely permitted. No transformation could span a block (or perhaps the inverse default). Straw vote: Do nothing | provide two "compilation" modes | provide "per line" control