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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
