[PATCH] D122220: [InlineAsm] Add support for address operands ("p").

[Jonas Paulsson via Phabricator via llvm-commits]

jonpa created this revision.
jonpa added reviewers: uweigand, niravd, coby, dsanders.
Herald added subscribers: dexonsmith, pengfei, hiraditya.
Herald added a project: All.
jonpa requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

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. 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.


https://reviews.llvm.org/D122220

Files:
  clang/lib/Basic/Targets/SystemZ.cpp
  clang/lib/Basic/Targets/SystemZ.h
  clang/lib/Basic/Targets/X86.cpp
  clang/test/CodeGen/SystemZ/systemz-inline-asm-03.c
  clang/test/CodeGen/asm.c
  llvm/include/llvm/CodeGen/TargetLowering.h
  llvm/include/llvm/IR/InlineAsm.h
  llvm/lib/CodeGen/CodeGenPrepare.cpp
  llvm/lib/CodeGen/GlobalISel/InlineAsmLowering.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
  llvm/lib/Target/SystemZ/SystemZISelDAGToDAG.cpp
  llvm/lib/Target/X86/X86ISelDAGToDAG.cpp
  llvm/test/CodeGen/SystemZ/inline-asm-addr.ll
  llvm/test/CodeGen/X86/inline-asm-p-constraint.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D122220.417233.patch
Type: text/x-patch
Size: 14315 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220322/32d6a57b/attachment.bin>