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