[all-commits] [llvm/llvm-project] 8484ba: [LangRef] Require elementtype attribute for indire...

Nikita Popov via All-commits all-commits at lists.llvm.org
Tue Jan 4 01:02:22 PST 2022

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 8484bab9cd5e5af11acf64e68c2f82e250e08dbe
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2022-01-04 (Tue, 04 Jan 2022)

  Changed paths:
    M llvm/docs/LangRef.rst
    M llvm/lib/IR/Verifier.cpp
    M llvm/test/Verifier/elementtype.ll
    A llvm/test/Verifier/inline-asm-indirect-operand.ll

  Log Message:
  [LangRef] Require elementtype attribute for indirect inline asm operands

Indirect inline asm operands may require the materialization of a
memory access according to the pointer element type. As this will
no longer be available with opaque pointers, we require it to be
explicitly annotated using the elementtype attribute, for example:

    define void @test(i32* %p, i32 %x) {
      call void asm "addl $1, $0", "=*rm,r"(i32* elementtype(i32) %p, i32 %x)
      ret void

This patch only includes the LangRef change and Verifier updates to
allow adding the elementtype attribute in this position. It does not
yet enforce this, as this will require changes on the clang side
(and test updates) first.

Something I'm a bit unsure about is whether we really need the
elementtype for all indirect constraints, rather than only indirect
register constraints. I think indirect memory constraints might not
strictly need it (though the backend code is written in a way that
does require it). I think it's okay to just make this a general
requirement though, as this means we don't need to carefully deal
with multiple or alternative constraints. In addition, I believe
that MemorySanitizer benefits from having the element type even in
cases where it may not be strictly necessary for normal lowering

Differential Revision: https://reviews.llvm.org/D116531

More information about the All-commits mailing list