I had a response on the cfe-dev (clang front end developers’ list) from one of the developers:
LLVM currently always spills “rm” constraints in order to simplify the
handling of inline asm in the backend (you can ask on llvmdev if you want
details). I don’t know of any plans to fix this in the near future.
So it’s clearly a ‘known’ issue. One of the goals of clang is to correctly handle gcc’s inline assembly syntax, amongst other extensions, which it does in this case – just not very efficiently. In short, this isn’t a bug, per se.
Since this isn’t a bug, I’m going to continue with the "r,m"
constraint syntax. I figure that this is the best compromise for now. gcc
will choose the best – presumably a register where possible – and clang
will force the use of a register by ignoring further options after the comma. If nothing else, it still preserves the semantic intent of the assembly statement, i.e., describing possible constraints, even if they are ignored.
A final note (20130715) : This particular example will not compile using the "r,m"
constraint in a single position – we would have to supply an alternative constraint match for each, e.g.,
: "=a,a" (rl), "=d,d" (rh) : "%0,0" (x), "r,m" (y)
This is required for multiple alternative constraints with GCC. But we’re getting into territory where GCC has been known to exhibit bugs in the past – whether or not this is true as of 4.8.1, I don’t know. Clang works without the alternatives in the other constraints, which is incompatible with GCC syntax, and must therefore be considered a bug.
If performance is critical, use "r"
, otherwise, stick with "rm"
and maybe clang will address this in the future, even as it benefits GCC.