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.
next prev parent 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