linux-gcc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Denis Zaitsev <zzz@anda.ru>
To: Andreas Jaeger <aj@suse.de>
Cc: Richard Henderson <rth@redhat.com>,
	libc-alpha@sources.redhat.com, linux-gcc@vger.kernel.org,
	gcc@gcc.gnu.org
Subject: Re: i386 inline-asm string functions - some questions
Date: Thu, 25 Dec 2003 06:13:38 +0500	[thread overview]
Message-ID: <20031225061338.D7419@zzz.ward.six> (raw)
In-Reply-To: <200312250039.hBP0dbGe011446@magilla.sf.frob.com>; from roland@redhat.com on Wed, Dec 24, 2003 at 04:39:37PM -0800

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.

      reply	other threads:[~2003-12-25  1:13 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-25  0:20 i386 inline-asm string functions - some questions Denis Zaitsev
2003-12-25  0:38 ` Richard Henderson
2003-12-25  1:15   ` Denis Zaitsev
2003-12-25  1:21     ` Zack Weinberg
2003-12-25  1:45       ` Denis Zaitsev
2003-12-26  3:40         ` Zack Weinberg
2003-12-27  4:58           ` Richard Henderson
2003-12-27 10:24             ` Zack Weinberg
2003-12-27 11:35               ` Denis Zaitsev
2003-12-27 18:38                 ` Zack Weinberg
2003-12-28 20:58                   ` Denis Zaitsev
2003-12-29  2:22                     ` Zack Weinberg
2003-12-29  2:44                       ` Denis Zaitsev
2003-12-29  2:46                         ` Zack Weinberg
2003-12-29  2:53                           ` Denis Zaitsev
2003-12-29  3:35                       ` Ulrich Drepper
2003-12-29  3:54                         ` Andrew Pinski
2003-12-29  6:57                           ` Jakub Jelinek
2003-12-29  3:56                         ` Zack Weinberg
2003-12-29  5:31                           ` Daniel Jacobowitz
2003-12-29  5:55                             ` Zack Weinberg
2003-12-29 18:37                             ` Denis Zaitsev
2003-12-29 19:09                               ` Zack Weinberg
2003-12-29 19:31                                 ` Denis Zaitsev
2003-12-29 19:37                                   ` Denis Zaitsev
2003-12-29 18:51                           ` Denis Zaitsev
2003-12-29 19:15                             ` Zack Weinberg
2003-12-27 10:52           ` Denis Zaitsev
     [not found]   ` <20031225060850.C7419@zzz.ward.six>
     [not found]     ` <20031225012711.GD13447@redhat.com>
2003-12-25  1:38       ` Denis Zaitsev
2003-12-25  1:53         ` Richard Henderson
2003-12-25  2:08           ` Denis Zaitsev
2003-12-25  0:39 ` Roland McGrath
2003-12-25  1:13   ` Denis Zaitsev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031225061338.D7419@zzz.ward.six \
    --to=zzz@anda.ru \
    --cc=aj@suse.de \
    --cc=gcc@gcc.gnu.org \
    --cc=libc-alpha@sources.redhat.com \
    --cc=linux-gcc@vger.kernel.org \
    --cc=rth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).