Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!umd5!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.arch Subject: Re: Memory latency / cacheing / scientific programs Message-ID: <12259@mimsy.UUCP> Date: 30 Jun 88 21:49:19 GMT References: <243@granite.dec.com> <779@garth.UUCP> <2033@pt.cs.cmu.edu> <11052@ames.arc.nasa.gov> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 29 >In article <6070@aw.sei.cmu.edu> firth@bd.sei.cmu.edu (Robert Firth) writes: >>... If the target machine has a large number of registers, then the >>codegenerator really must be prepared to perform global register >>allocation .... In article <11052@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: >If by "global" you mean, at the module level, then the answer is yes. The >optimizers go far beyond peephole type optimizations. But if you mean >global for an entire process, no. Which is why all registers that are >used in a module have to be restored. I think by `global' he means what I mean by `global': at the process level. (It bothers me that people talk about per-function optimisation, or even per-module, as `global optimisation'. Global means global, not function-level, not module-level. One would not call the variable `t' below global: f(x: real) { t: int; t := floor(x); ... } so why is optimisation that puts `t' in a register for the duration of `...' called `global'?) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris