[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