This is the mail archive of the gcc@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: asm issues


In article <8857.926057666@upchuck.cygnus.com>,
Jeffrey A Law  <law@upchuck.cygnus.com> wrote:
>
>
>  > Actually I see now that my remarks, too, underrated decent points-to
>  > analysis. There is no particular reason why (*foo) can't be kept in a
>  > register by an intelligent enough compiler, and I know for a fact that
>  > there are compilers that routinely do it.
>gcc is among those compilers.  Though it's support for this kind of thing
>isn't as aggressive as other compilers.  Expect that to be changing :-)

How about a more subtle change to gcc would think about "m" arguments to
asms?

Would it not make sense to say that we're really passing the asm just
the _address_ of a "m" argument? After all, that's really what the code
generated does: if you do

	asm("lea %1,%0":"=r" (reg):"m" (memory));

then the output will in fact have nothing at all to do with the memory
contents, and only the address. 

If gcc thought of the problem as equivalent with passing a memory
address to a function, suddenly points-to analysis is no longer a
problem: it becomes very obvious what gcc has to do, because you
suddenly don't even know whether maybe the function (read "asm") might
save away the pointer for later use etc.. 

Also note how "m" in general is quite different from the other asm
constraints: all the others are obviously "pass-by-value", and can't
really be used any other way.  While "m" can most obviously be
considered to be pass-by-reference - making the whole problem just go
away (ie suddenly gcc very obviously cannot pass any other memory
location to the asm, and there is no question about what gcc should or
should not do). 

Is this inherently hard to do?

		Linus


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