This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: i386 inline-asm string functions - some questions
- From: Denis Zaitsev <zzz at anda dot ru>
- To: Andreas Jaeger <aj at suse dot de>
- Cc: Richard Henderson <rth at redhat dot com>, libc-alpha at sources dot redhat dot com,linux-gcc at vger dot kernel dot org, gcc at gcc dot gnu dot org
- Date: Thu, 25 Dec 2003 06:13:38 +0500
- Subject: Re: i386 inline-asm string functions - some questions
- References: <20031225052045.A18774@zzz.ward.six> <200312250039.hBP0dbGe011446@magilla.sf.frob.com>
On Wed, Dec 24, 2003 at 04:39:37PM -0800, Roland McGrath wrote:
> > >From some moment in the past, the next input parameters are used here
> > and there in sysdeps/i386/i486/bits/string.h:
> >
> > "m" ( *(struct { char __x[0xfffffff]; } *)__s)
> >
> > When I was seeking for the reasons to do so, I've found some
> > discussions about this in libc-alpha and gcc mailing lists. As I
> > understand from there, there are an options - to use the "m" arg(s)
> > shown above or just to use "memory" in the list of a clobbered
> > registers. So, the question is: why the "m"-way had been choosen?
>
> The reason we use this kind of "m" constraint is that it indicates what we
> want to say: memory __s points to might be used. That means that if the C
> aliasing rules allow the compiler to assume that a given other expression
> cannot point to the same memory as __s does, it is free to do so and
> optimize out stores through unrelated pointers that cannot affect __s.
> Conversely, a "memory" clobber tells the compiler that it must assume that
> all memory any pointer points to might be read by this asm.
Yes, I understand all this. But in that discussion in past the
similar question was already touched - the "precise" "m"-way doesn't
get any real-life benefit.
> > I'm asking, because I've found that this "m"-way leads GCC to produce
> > an unoptimal enough assembler, while "memory" code is ok.
>
> That is an issue for GCC.
Yes, I have no way other than just to agree...
> It is correct for glibc (and other code) to use the asm constraints
> that express the true precise set of constraints and tell the
> compiler it is free to do us much as is in fact safe. As to whether
> your "+&r" constraints on the pointer values are correct, I don't
> know.
"+&r" is just a shortcut for :"=&r":"0":. It's correct and doesn't
touch the "m" issue.