This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: Fix 20000724-1.c




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

	int result;

	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.

		Linus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]