Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!world!iecc!compilers-sender From: mike@vlsivie.tuwien.ac.at (Michael K. Gschwind) Newsgroups: comp.compilers Subject: Re: Parameter Passing Via Registers Keywords: registers, optimize Message-ID: <9105031247.AA00594@slave.vlsivie.tuwien.ac.at> Date: 3 May 91 19:42:45 GMT References: <1991May1.144334.5109@ncsu.edu> Sender: compilers-sender@iecc.cambridge.ma.us Reply-To: Michael K. Gschwind Organization: Compilers Central Lines: 59 Approved: compilers@iecc.cambridge.ma.us Dr. Jon Mauney writes: >Most of the discussion has mentioned ways of forcing parameters passed in >registers onto the stack for non-local reference. Note that it is not >strictly necessary for such parameters to be on the stack. Since the >references occur within internal functions, code could be compiled to use >the value in the register. You would have to change the calling sequence >so as to preserve the register, but you have control of both sides of the >call, so that is possible. Conceivably, this could be done even if the >procedure is passed as a parameter -- just make sure the register value is >part of the closure that you pass. > >I'm not claiming it's worth the trouble... It IS worth the trouble if you're doing global register allocation or at least register allocation relative to a top-level function and its nested procedures. IT IS (probably) NOT worth it if you're only trying to prevent forcing parameters on the stack because they are used in some nested procedures. You might of course find a simple algorithm which would not cost much, but to be really effective, you'd probably have to do extensive data flow analysis. Parameters used in nested procedures are (probably) too rare warrant such extensive data flow analysis. But if you're doing data flow analysis anyway, you'll probably get it for free. You can then probably apply the strategy adopted for local variables used in nested functions to parameters as well (or vice versa ;-). You write that "this could be done even if the procedure is passed as a parameter". This is not correct in the general case, and the case you line out, namely "just make sure the register value is part of the closure that you pass", is not feasable. Procedures passed as parameters can be called from just about any context, e.g., library functions, separately compiled modules etc., thus you cannot change the calling sequence. In the case of functions passed as parameters/procedure typed variables, you always have to have a standardized calling sequence. You could of course always store the calling conventions of every function in a library or external module in a data base, but what do you do if you are PascalWorkstations, Inc. and your shared library has a bug? You have to keep the same calling conventions for a function 'x' once you have sold a single copy of a shared library containing it, or all programs linked with the new, improved shared library, but compiled with the old one (i.e., all commercial programs sold for your workstation) will no longer work! Modula-2 is much easier here: if you want to do aggressive register allocation, you can optimize all top-level functions + their nested functions, while retaining a consistent calling convention for top-level functions, which are the only functions which may be assigned to procedure-typed variables. bye, mike Michael K. Gschwind, Dept. of VLSI-Design, Vienna University of Technology mike@vlsivie.tuwien.ac.at || mike@vlsivie.uucp Voice: (++43).1.58801 8144 || Fax: (++43).1.569697 -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.