Question

I’m having difficulty understanding the role constraints play in GCC inline assembly (x86). I’ve read the manual, which explains exactly what each constraint does. The problem is that even though I understand what each constraint does, I have very little understanding of why you would use one constraint over another, or what the implications might be.

I realize this is a very broad topic, so a small example should help narrow the focus. The following is a simple asm routine which just adds two numbers. If an integer overflow occurs, it writes a value of 1 to an output C variable.

 int32_t a = 10, b = 5;
 int32_t c = 0; // overflow flag

 __asm__
 (
  "addl %2,%3;"        // Do a + b (the result goes into b)
  "jno 0f;"            // Jump ahead if an overflow occurred
  "movl $1, %1;"       // Copy 1 into c
  "0:"                 // We're done.

  :"=r"(b), "=m"(c)    // Output list
  :"r"(a), "0"(b)     // Input list
 );

Now this works fine, except I had to arbitrarily fiddle with the constraints until I got it to work correctly. Originally, I used the following constraints:

  :"=r"(b), "=m"(c)    // Output list
  :"r"(a), "m"(b)     // Input list

Note that instead of a “0”, I use an “m” constraint for b. This had a weird side effect where if I compiled with optimization flags and called the function twice, for some reason the result of the addition operation would also get stored in c. I eventually read about “matching constraints“, which allows you to specify that a variable is to be used as both an input and output operand. When I changed "m"(b) to "0"(b) it worked.

But I don’t really understand why you would use one constraint over another. I mean yeah, I understand that “r” means the variable should be in a register and “m” means it should be in memory – but I don’t really understand what the implications of choosing one over another are, or why the addition operation doesn’t work correctly if I choose a certain combination of constraints.

Questions: 1) In the above example code, why did the “m” constraint on b cause c to get written to? 2) Is there any tutorial or online resource which goes into more detail about constraints?

Answer 1

Here’s an example to better illustrate why you should choose constraints carefully (same function as yours, but perhaps written a little more succinctly):

bool add_and_check_overflow(int32_t& a, int32_t b)
{
    bool result;
    __asm__("addl %2, %1; seto %b0"
            : "=q" (result), "+g" (a)
            : "r" (b));
    return result;
}

So, the constraints used were: q, r, and g.

• q means only eax, ecx, edx, or ebx could be selected. This is because the set* instructions must write to an 8-bit-addressable register (al, ah, …). The use of b in the %b0 means, use the lowest 8-bit portion (al, cl, …).
• For most two-operand instructions, at least one of the operands must be a register. So don’t use m or g for both; use r for at least one of the operands.
• For the final operand, it doesn’t matter whether it’s register or memory, so use g (general).

In the example above, I chose to use g (rather than r) for a because references are usually implemented as memory pointers, so using an r constraint would have required copying the referent to a register first, and then copying back. Using g, the referent could be updated directly.

---

As to why your original version overwrote your c with the addition’s value, that’s because you specified =m in the output slot, rather than (say) +m; that means the compiler is allowed to reuse the same memory location for input and output.

In your case, that means two outcomes (since the same memory location was used for b and c):

• The addition didn’t overflow: then, c got overwritten with the value of b (the result of the addition).
• The addition did overflow: then, c became 1 (and b might become 1 also, depending on how the code was generated).