[CodeGen] Enhance inline asm constraint diagnostics

[e-kud]

No description provided.

[e-kud]

This is a continuation of #96363. Here I want backends to provide additional information why a register can't be allocated.

My points of concerns:

• I don't like using std::string for error messages.
• I've tried to return Expected<std::pair<unsigned, const TargetRegisterClass *>> from getRegForInlineAsmConstraint. But this is much more intrusive change than simply adding the reference argument. Because we need to update all return statements in all backends.
• In case of X86, TargetLowering::getRegForInlineAsmConstraint may override the error message obtained from switches before. But it's not a problem to preserve a message if any, and ignore the one from generic version.

Hi @arsenm @RKSimon @efriedma-quic @phoebewang what do you think? Are there better ways to make backends more friendly in terms of diagnostics.

This is a draft. When or if we agree with the approach, I'll cover all failures from getRegForInlineAsmConstraint for X86. For now I've covered only cases from tests.

[efriedma-quic]

Maybe we can be more specific? Something like "expected an integer, found v8i16"?

[e-kud]

This is hard. To be precise and informative we need to name all the vector combinations that can fit in 128 bits in case of 'x' constraint and even naming is not simple, as we need to understand whether v8f16 is available or not to include it into the message. Or do you mean r constraint in particular?

[efriedma-quic]

Maybe SmallStringImpl&?

I don't really see how you can do much better than that; an error message is, ultimately, just a string, given we don't support translation or anything like that.

[arsenm]

Error or StringError?

[e-kud]

I like the idea of SmallString. Error and StringError, they consist of std::string and additionally have a return code that we don't have use of.

Ok, since there aren't strong points for using something like Expected, I'll continue with returning an error message by reference.

[arsenm]

Out argument string message is a worse API. I would prefer to use one of the proper return with bundled error message options