This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: Fix 20000724-1.c
- To: Geoff Keating <geoffk at geoffk dot org>
- Subject: Re: PATCH: Fix 20000724-1.c
- From: Linus Torvalds <torvalds at transmeta dot com>
- Date: Tue, 1 May 2001 14:04:53 -0700 (PDT)
- cc: <gcc-patches at gcc dot gnu dot org>
On 1 May 2001, Geoff Keating wrote:
> asms are not quite like subroutine calls. For instance, in this routine:
> int something(void)
> int result;
> result = get_something ();
> /* something here (perhaps just a complicated expression that runs
> the machine out of registers) that forces 'result' into memory */
> asm ("whatever" : : : "memory");
> return result;
> If 'result' is in memory, then it needs to be re-loaded after the
> 'asm' statement; but if the 'asm' was a call, then 'result' could
> be loaded before the call if that looked like a good idea.
I don't agree.
Even if "result" was was allocates space on the stack, the compiler can
(and should) legally avoid reloading it, because the asm _cannot_know_
that "result" is in memory.
So I will claim that you can do all the same optimizations around the asm
as you could do around a function call. Indeed, you can obviously do a few
extra ones - you don't have call-clobbered registers, so you have more
registers free around it. And if it doesn't have a memory clobber, you can
do even more optimizations.
Note what happens if you have
fn( &result );
asm("whatever" : : :"memory");
Now, we've taken the _address_ of result, and we've passed it into a black
hole, and now the compiler can no longer know that result cannot be
modified. So with something like the above, yes, the compiler has to
re-load the value of "result".
But note how this is _exactly_ the same as with a function call. The
decision and the dependency tracking are 100% the same.