[PATCH] D101538: [GlobalISel][IRTranslator] Make translate() methods virtual.

Aleksandr Bezzubikov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 13 12:13:46 PDT 2021


zuban32 added a comment.

Let me explain my problem with a short example. Assume we have the following IR:

  define @foo(i32* addrspace(3) %v.addr) {
  %0 = load i32 i32* addrspace(3) %v.addr
  ...
  }

In our target this type info will require 2 additional instructions, so after instruction selection the code should look like:

  r0 = OpIntegerType 32         // op0: integer width
  r1 = OpPointerType r0, 3      // op0: base type, op1: addrspace
  ...
  r2 = OpParam r1     // op0: the actual type of the func's argument
  r3 = OpLoad r0, r2  // op0: 'ResultType', op1: the actual operand

In order to generate the type instructions we need the original LLVM type info, but also it's required to keep the mapping of these types to the vregs generated by the IRTranslator so that this 'ResultType' field would be correctly set at the later GISel stages.
But if we don't intervene into the IR translation process, I don't see how it is possible to obtain this mapping.
Speaking about DBG_VALUE - I'm not quite familiar with it, but FWIW it seems that it uses some metadata nodes as its operand, is it correct?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101538/new/

https://reviews.llvm.org/D101538



More information about the llvm-commits mailing list