[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