[PATCH] D57027: [AMDGPU] Factored PAL metadata handling out into its own class
Scott Linder via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Mar 19 07:37:11 PDT 2019
scott.linder accepted this revision.
scott.linder added a comment.
This revision is now accepted and ready to land.
LGTM, thanks! I think you can also drop "provides a method for use by LLPC to write metadata into LLVM IR" from the commit message.
================
Comment at: lib/Target/AMDGPU/Utils/AMDGPUPALMetadata.cpp:41-45
+ for (unsigned I = 0, E = Tuple->getNumOperands() & -2; I != E; I += 2) {
+ auto Key = mdconst::dyn_extract<ConstantInt>(Tuple->getOperand(I));
+ auto Val = mdconst::dyn_extract<ConstantInt>(Tuple->getOperand(I + 1));
+ if (!Key || !Val)
+ continue;
----------------
tpr wrote:
> scott.linder wrote:
> > Even if you keep going with whatever you can get out of the IR, if it is malformed I would emit some sort of diagnostic. Maybe return a `bool` like in `setFromBlob` and emit a diagnostic in `AMDGPUAsmPrinter::EmitStartOfAsmFile`?
> Val==0 is certainly not malformed, it's just that we don't need a map entry for a 0 value register. Key==0 is arguably malformed, but I think LLPC actually does it, so I would rather not emit a diagnostic for it.
That make sense, but what about cases where `Tuple->getNumOperands()` is odd? It seems like values are just silently ignored? In the end the values are probably not being edited, and you will be deleting this code, so I'm OK with dropping the odd value.
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D57027/new/
https://reviews.llvm.org/D57027
More information about the llvm-commits
mailing list