This patch adds support for inline assembly address operands using the "p" constraint.
This is in fact broken on X86, see example at https://reviews.llvm.org/D110267 (Nov 23). As suggested there, here is the basic support for "p" and introduction of the C_Memory ConstraintType which fixes this bug on X86 (and also adds support for "p" on SystemZ).
Reasoning:
Memory ("m") and Address ("p") are operands that are selected (and printed) the same way by the backend (i.e. "select address"), but on the other hand they are also different as "p" takes an address present at the source level, while "m" causes the address of a value to be passed (indirect). For example, "p" should not get the mayLoad flag.
The different inline asm operand types are handled in InlineAsm.h but also in TargetLowering: An "m" operand is an InlineAsm::Kind_Mem but also a TargetLowering::C_Memory.
InlineAsm supports different constraint codes for memory operands so that the code gets shifted into its place in Flags. I have reused this for address operands by simply adding a new memory constraint "Constraint_p" for "p". I haven't found a reason yet to add a new InlineAsm::Kind_Address, so addresses are InlineAsm::Kind_Mem with Constraint_p.
In TargetLowering I similarly started out by treating "p" as C_Memory, but we then decided to instead introduce a new C_Address ConstraintType. It seems to make sense to have a different type here as they are in some cases treated differently in SelectionDAGBuilder.
Not sure if it is too confusing to have an address be a Kind_Mem and then a C_Address instead of C_Memory, but it kind of makes sense to me. I could possibly imagine renaming Kind_Mem to Kind_MemOrAddr.
X86:
X86TargetInfo::validateAsmConstraint(): I don't know why not 'm' is accepted here..? I think 'p' should also be recognized here, but the test case passes without it...
X86 test cases in clang/test/CodeGen/asm.c and llvm/test/CodeGen/X86/inline-asm-p-constraint.ll.
CodeGenPrepare:
It seems that addresses could be handled just like memory operands, given that they are handled the same by the back-end. "TODO comments" added for this.
GlobalISel:
@npopov: GlobalISel has not really been handled, but C_Address has been added in switch statements to silence warnings.
Did you check the difference with the previous constraint "im" at llvm end.
Looks the C_Address is mostly same with C_Memory, but no relation with C_Immediate.