- Distinct metadata needs generating in the codegen to attach correct AAInfo on the loads/stores after lowering, merging, and other relevant transformations.
- This patch adds 'MachhineModuleSlotTracker' to help assign slot numbers to these newly generated unnamed metadata nodes.
- To help 'MachhineModuleSlotTracker' track machine metadata, the original 'SlotTracker' is rebased from 'AbstractSlotTrackerStorage', which provides basic interfaces to create/retrive metadata slots. In addition, once LLVM IR is processsed, additional hooks are also introduced to help collect machine metadata and assign them slot numbers.
- Finally, if there is any such machine metadata, 'MIRPrinter' outputs an additional 'machineMetadataNodes' field containing all the definition of those nodes.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Revise that machine tracker a bit to ensure machine metadata is alway per-function state.
- The printer of the machine function is done on a per-function wise. That makes the scanning of machine data through module unnecessary and problematic as MF may be removed deliberately under certain cases. I found that issue when validating the parser support.
Unfortunately I don't know anything about MIR -- adding @arsenm who I think should be familiar with this, or at least know someone who is :)
Thanks for doing this, this has been painful forever.
Can you add some plain mir tests in test/CodeGen/MIR?
llvm/include/llvm/CodeGen/MIRYamlMapping.h | ||
---|---|---|
707 | Is this just for the metadata nodes attached to the function itself? | |
llvm/unittests/CodeGen/MachineMetadata.cpp | ||
124 | EXPECT_EQ | |
156 | EXPECT_EQ | |
328–329 | Only need the hasOneMemOperand |
the patch is revised following comments.
llvm/include/llvm/CodeGen/MIRYamlMapping.h | ||
---|---|---|
707 | 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. |
llvm/include/llvm/CodeGen/MIRYamlMapping.h | ||
---|---|---|
707 | 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 |
llvm/include/llvm/CodeGen/MIRYamlMapping.h | ||
---|---|---|
707 | 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. |
Needs standalone MIR tests (i.e. round trip tests not bundled in a unit test)
Also I would like to see some tests where there are inconsistencies between the metadata present in the IR section, and the explicit metadata in the MIR
round-trip needs parser support (under review @ https://reviews.llvm.org/D103282), where cases with mixed metadata are also included. Shall we merge them into one?
PING for the further comment on the round-trip test, which requires MIR parser support reviewed @ D103282
Is this just for the metadata nodes attached to the function itself?