[clang] [llvm] RFC: Implementing new mechanism for hard register operands to inline asm as a constraint. (PR #85846)

Stefan Schulze Frielinghaus via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 9 06:38:46 PST 2025


stefan-sf-ibm wrote:

Currently I've implemented/documented constraints consisting of single hard register constraints only since this is the most basic feature and I'm still running into RA problems in certain cases for those.  Once those are fixed I would like to move on and have a look at how to implement multiple constraints involving hard register constraints.  I haven't fully wrapped my head around those.  There are certainly cases like constraint `{r5}r` should be equivalent to `r`, if register `r5` is contained in the register class associated with constraint `r` which is more obvious than maybe other cases. In general, having the possibility to come up with "ad-hoc" register classes via hard register constraints as e.g. `{r3}{r4}{r7}` is valuable (one could also think of syntactic sugar like having a set-like notation `{r3,r4,r7}`).

This brings me to register asm and hard register constraints.  If the constraint is a single hard register constraint and the operand a register asm object and both coincide in the register, then I don't see a reason to reject this.  That being said, currently I accept this in GCC and as you said, if multiple constraints are involved and at least one is compatible with the register asm, then this could work, too.  Though, this is where it becomes a bit more complicated since GCC and Clang do not always coincide here.  Assume `f5` is not contained in the register class associated with constraint `r`, then for

```
register long x asm ("f5");
asm ("" : "=r" (x));
```

we have that GCC assigns to the operand some register which is compatible with constraint `r` and therefore is different than `f5` coming from register asm, whereas Clang assigns register `f5` coming from register asm and ignores the constraint.  That being said I haven't come up with a complete set of rules here but I certainly would love to see GCC and Clang being compatible here!

https://github.com/llvm/llvm-project/pull/85846


More information about the llvm-commits mailing list