This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: i386 inline-asm string functions - some questions


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.


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