Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: "Daniel Jacobowitz" <dan@debian.org>, <linux-mips@oss.sgi.com>
Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs
Date: Mon, 28 May 2001 15:48:09 +0200	[thread overview]
Message-ID: <005901c0e77c$dae9f2e0$0deca8c0@Ulysses> (raw)
In-Reply-To: Pine.GSO.3.96.1010528131446.15200C-100000@delta.ds2.pg.gda.pl

> > says that "Q" through "U" are reserved for use with EXTRA_CONSTRAINT
> > in machine-dependent definitions of arbitrary operand types.  When
> > and where does it get bound for MIPS gcc, and what is it supposed
> > to mean?  If I compile this kind of fragment using a "m" constraint,
> > it seems to do the right thing, at least on my archaic native compiler.
>
>  Is it gcc generating right code or gas expanding a macro?  Try `gcc -S'
> -- for me "m" generates "lw $0,262144($2)", which is unacceptable when
> ".set noat" is in effect (and perfectly fine otherwise).

I'd been disassembling the resulting .o files, as I didn't care whether
it's the compiler or the assembler that ultimately makes things right.
Repeating your experiment using -S gives the following results:

egcs-2.90.29 (native) and
egcs-2.91.66 (x86 cross) : Optimiser produces "impossible" load
                                              offset you describe if "m"  or
"o" constraint,
                                              compiler barfs if "R"
constraint.

gcc 2.96-mips3264-000710 from Algorithmics (x86 cross):
                                              Compiler generates "correct"
code
                                              (Address is calculated with an
explicit
                                               add prior to the asm
expansion) for
                                               any of the three constraints.

However, if one compiles all the way to object code and looks
at what the assembler is actually doing with those "impossible"
offsets under gcc 2.90 and 2.91, technically, it's not violating ".noat"
in the "m" and "o" constraint  cases.   It is *not* using the "at" register.
It is, however, cleverly using the load destination  register as a temporary
to calculate  the correct address.  As there are no memory operations,
these instructions should have no effect  on the correct execution
of the ll/sc sequence  (though they will  increase the statistical
probability
of a context  switch between ll and sc).

            Regards,

            Kevin K.

WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Daniel Jacobowitz <dan@debian.org>, linux-mips@oss.sgi.com
Subject: Re: [PATCH] incorrect asm constraints for ll/sc constructs
Date: Mon, 28 May 2001 15:48:09 +0200	[thread overview]
Message-ID: <005901c0e77c$dae9f2e0$0deca8c0@Ulysses> (raw)
Message-ID: <20010528134809.AU7apetUAg2cm-xr4hv-sXn7lI7f9F6gkQkNjn-HYzE@z> (raw)
In-Reply-To: Pine.GSO.3.96.1010528131446.15200C-100000@delta.ds2.pg.gda.pl

> > says that "Q" through "U" are reserved for use with EXTRA_CONSTRAINT
> > in machine-dependent definitions of arbitrary operand types.  When
> > and where does it get bound for MIPS gcc, and what is it supposed
> > to mean?  If I compile this kind of fragment using a "m" constraint,
> > it seems to do the right thing, at least on my archaic native compiler.
>
>  Is it gcc generating right code or gas expanding a macro?  Try `gcc -S'
> -- for me "m" generates "lw $0,262144($2)", which is unacceptable when
> ".set noat" is in effect (and perfectly fine otherwise).

I'd been disassembling the resulting .o files, as I didn't care whether
it's the compiler or the assembler that ultimately makes things right.
Repeating your experiment using -S gives the following results:

egcs-2.90.29 (native) and
egcs-2.91.66 (x86 cross) : Optimiser produces "impossible" load
                                              offset you describe if "m"  or
"o" constraint,
                                              compiler barfs if "R"
constraint.

gcc 2.96-mips3264-000710 from Algorithmics (x86 cross):
                                              Compiler generates "correct"
code
                                              (Address is calculated with an
explicit
                                               add prior to the asm
expansion) for
                                               any of the three constraints.

However, if one compiles all the way to object code and looks
at what the assembler is actually doing with those "impossible"
offsets under gcc 2.90 and 2.91, technically, it's not violating ".noat"
in the "m" and "o" constraint  cases.   It is *not* using the "at" register.
It is, however, cleverly using the load destination  register as a temporary
to calculate  the correct address.  As there are no memory operations,
these instructions should have no effect  on the correct execution
of the ll/sc sequence  (though they will  increase the statistical
probability
of a context  switch between ll and sc).

            Regards,

            Kevin K.

  reply	other threads:[~2001-05-28 13:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-23 21:52 [PATCH] incorrect asm constraints for ll/sc constructs Daniel Jacobowitz
2001-05-24 13:42 ` Maciej W. Rozycki
2001-05-24 23:44   ` Daniel Jacobowitz
2001-05-25 13:13     ` Maciej W. Rozycki
2001-05-25 21:15       ` Kevin D. Kissell
2001-05-25 21:15         ` Kevin D. Kissell
2001-05-25 21:49         ` Daniel Jacobowitz
2001-05-26 22:14           ` Kevin D. Kissell
2001-05-26 22:14             ` Kevin D. Kissell
2001-05-26 22:23             ` Ralf Baechle
2001-05-28 11:20             ` Maciej W. Rozycki
2001-05-28 13:48               ` Kevin D. Kissell [this message]
2001-05-28 13:48                 ` Kevin D. Kissell
2001-05-28 13:59                 ` Maciej W. Rozycki
2001-05-25 20:27   ` Ralf Baechle
2001-05-25 20:49     ` Daniel Jacobowitz
2001-05-28 11:09       ` Maciej W. Rozycki
2001-05-30  0:17       ` Daniel Jacobowitz
2001-05-30  7:02         ` Kevin D. Kissell
2001-05-30  7:02           ` Kevin D. Kissell

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='005901c0e77c$dae9f2e0$0deca8c0@Ulysses' \
    --to=kevink@mips.com \
    --cc=dan@debian.org \
    --cc=linux-mips@oss.sgi.com \
    --cc=macro@ds2.pg.gda.pl \
    /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