This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
paradox re: constraints for ReadWrite memory in asm instruction
- From: dw <limegreensocks at yahoo dot com>
- To: gcc-help at gcc dot gnu dot org
- Date: Sun, 24 Mar 2013 17:16:16 -0700
- Subject: paradox re: constraints for ReadWrite memory in asm instruction
I am trying to figure out the proper constraints for __asm__
instructions on x64 that both read and write memory (for example "bts"
or "lock xadd"). I'm ok writing the assembler, I'm just struggling with
writing the constraints. My problem is that the gcc docs forbid every
permutation of constraint I can think of that would define this
behavior. You have 3 mutually exclusive requirements:
1) Since the value being read+written is memory, the memory must be
specified as both input and output.
2) The docs say: "You should only use read-write operands when the
constraints for the operand [...] allow a register."
3) The docs say: "You may not write a clobber description in a way that
overlaps with an input or output operand. [...] There is no way for you
to specify that an input operand is modified without also specifying it
as an output operand."
In summary: You have to specify something for output, but you can't have
"=m" (#1) or "+m" (#2) for output, and you can't fake the output by
using a clobber constraint against the address (#3).
Which effectively means there is *no* way to specify a memory constraint
as read+write. Since I don't believe that is true, I can only assume
the docs are wrong. The question is: which part?
I have seen a bunch of code that uses constraints that violate these
documented requirements. I am sure that most of them work (at least
most of the time). But I don't want to base my program on code that I
know violates the docs. That's just asking for trouble.
I'm looking for the officially supported and documented way to specify
memory constraints as read+write. And obviously I want what I write to
produce the most performant code consistent with supported standards.
Thanks.