Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!world!iecc!compilers-sender From: preston@ariel.rice.edu (Preston Briggs) Newsgroups: comp.compilers Subject: Re: Parameter Passing Via Registers Keywords: optimize, registers, Pascal, Modula Message-ID: <1991Apr30.151911.24753@rice.edu> Date: 30 Apr 91 15:19:11 GMT References: <1991Apr30.022048.4539@iecc.cambridge.ma.us> Sender: compilers-sender@iecc.cambridge.ma.us Reply-To: preston@ariel.rice.edu (Preston Briggs) Organization: Rice University, Houston Lines: 45 Approved: compilers@iecc.cambridge.ma.us Chuck Lins writes: >Does anyone know how nested procedures affect the ability to pass parameters >via registers? If there was no up-level access everything would work fine, >but with this facility you get all sorts of problems. Uplevel access would >also seem to affect dataflow analysis (the compiler could think that a >variable is 'dead' when in reality it's going to get accessed by a nested >local procedure. One approach would be to pass the first few parameters in registers. However, in the called routine, it may be necessary to store the parameters on the stack, in standard locations. Imagine we have 3 procedures: A, B, and C, where C is nested inside B. When A calls B, it can pass (say) the first 4 suitable arguments in registers (where suitable means not a record or array). When C is compiled (it's compiled before B, since it's nested), we record which of B's parameters and variables are referenced. For each uplevel reference, we assume that the values are in some standard place on the stack. When compiling B, we must leave space on the stack for all the parameters. When we see a call to C, we know which variables and parameters might be accessed in C, and must emit code to store any "enregistered" variables into their home locations on the stack. Note that we must also recognize the effects of any procedures nested within C. The above version is "flow-insensitive" analysis, in that we assume that any reference can be reached and we don't bother about noticing whether DEFs come before USEs. It sounds slightly hairy, but really it's just setting a couple of flags per variable in the symbol table, and then following conventions while generating code. A more precise version would be "flow-sensitive". Here we do a little more work to recognize that a variable is always DEF'd before USE, and is therefore dead. This is all pretty informal and will take some effort to fill out the details. We're (probably) saved from the effort of complete call graph construction and interprocedural analysis by the fact that we're considering only lexically scoped procedures, without first-class procedures. Preston Briggs -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.