[PATCH] D105142: RFC: Implementing new mechanism for hard register operands to inline asm as a constraint.

[Anirudh Prasad via Phabricator via cfe-commits]

anirudhp added a comment.

In D105142#2862592 <https://reviews.llvm.org/D105142#2862592>, @jyknight wrote:

> This code doesn't handle multiple alternatives in a constraint.
>
> E.g. `"={eax}{ebx}"` or `"={eax}{ebx},m"`.
>
> See the GCC docs for the C-level syntax
> https://gcc.gnu.org/onlinedocs/gcc/Multi-Alternative.html#Multi-Alternative
> and LLVM IR docs for the IR syntax:
> https://llvm.org/docs/LangRef.html#constraint-codes
>
> LLVM doesn't handle alternatives very well in the backend, but Clang at least should parse and properly generate LLVM asm strings for these cases I think.

You're right, when it came to the {...} constraint, initially I purposely errored out when there were multiple constraints after {.*}. To me, it didn't make sense to issue another constraint when you're already being specific enough by asking the backend to use a specific register. For example, the AMDGPU target, currently errors out when you have something like "{reg-name}a". Ideally if its an option, I'd like to make it even more strict to ensure that there is no other constraint applied with {.*}. Ie. if a user specifies a hard register constraint, only emit that, otherwise diagnose as an error, because a hard register constraint is quite specific to begin with. Maybe this could be documented as a special feature (a standalone constraint, can't be used as a multi-alternative constraint) since this is something new? (From the backend's perspective, is it a valid scenario to try to allocate two registers for an operand? will the last one occurring be the one allocated? what happens if the user wanted the "first" register?)

If not, I have no issue with changing it to emit multiple constraints in the IR, but I'd like to get your thoughts on the above first.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105142/new/

https://reviews.llvm.org/D105142