[PATCH] D103205: [MIRPrinter] Add machine metadata support.
Michael Liao via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri May 28 08:50:03 PDT 2021
hliao added inline comments.
================
Comment at: llvm/include/llvm/CodeGen/MIRYamlMapping.h:707
MachineJumpTable JumpTableInfo;
+ std::vector<StringValue> MachineMetadataNodes;
BlockStringValue Body;
----------------
arsenm wrote:
> hliao wrote:
> > arsenm wrote:
> > > Is this just for the metadata nodes attached to the function itself?
> > yes, as 'printMIR' inherently works per function wise, the metadata here refers to ones attached to the specified MF. So far, metadata generated in the backend are all unnamed ones and only referenced within that function only.
> > Furthermore, our MIR/MF in some tools may be removed in a function-pass ('createFreeMachineFunctionPass'). That makes the whole machine module inconsistent between prints of different MFs.
> >
> So the intent is you do not need the IR section to use the metadata? I had assumed this would directly read from the IR. I'm all for breaking the IR dependency but wondering what happens if the IR section metadata is inconsistent with the MIR section metadata
those metadata is generated directly within the backend instead of reading from IR. For instance, in D102255, new scoped AA metadata is generated when lowering memcpy into machine instructions. In D102821, when two stores are merged, potentially we need a new scoped AA metadata as the new scope should be the union of that 2 stores and the new scoped no-alias should be the intersect. In short, with the newly introduced scoped AA metadata, the backend may need to generate new metadata, which could not be referenced directly from IR.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D103205/new/
https://reviews.llvm.org/D103205
More information about the llvm-commits
mailing list