This is an archive of the discontinued LLVM Phabricator instance.

[mlir][llvm] Make the import of LLVM IR metadata extensible.
ClosedPublic

Authored by gysit on Dec 22 2022, 7:46 AM.

Details

Summary

This revision extends the LLVMImportDialectInterface to make the import
of LLVM IR instruction-level metadata extensible. It extends the
signature of the existing dialect interface to provide a method to
import specific metadata kinds and attach them to the imported
operation. The conversion function can rely on the ModuleImport class
to perform support tasks.

The revision implements the second part of the
"extensible llvm ir import" rfc:
https://discourse.llvm.org/t/rfc-extensible-llvm-ir-import/67256/6

The interface method names changed a bit compared to the suggested
design. The hook to set the instruction level metadata is now called
setMetadataAttrs and takes the metadata kind as an additional parameter.
We do not hand in the original LLVM IR instruction since it is not used
at this point. Importing named module-level meta data can be added in a
later stage after gaining some experience with this extension mechanism.

Depends on D140374

Diff Detail

Event Timeline

gysit created this revision.Dec 22 2022, 7:46 AM
Herald added a project: Restricted Project. · View Herald Transcript
gysit requested review of this revision.Dec 22 2022, 7:46 AM
Dinistro added inline comments.Dec 22 2022, 11:29 PM
mlir/lib/Target/LLVMIR/Dialect/LLVMIR/LLVMIRToLLVMImport.cpp
84

I'm not too familiar with the details of the metadata nodes. Is it guaranteed that each node has at least 1 operand? If so, I would probably still add an assertion.

135

This code can be reached by a user passing in an invalid kind. I would suggest to return failure() instead.

gysit updated this revision to Diff 485068.Dec 23 2022, 1:30 AM
gysit marked an inline comment as done.

Address review comments.

mlir/lib/Target/LLVMIR/Dialect/LLVMIR/LLVMIRToLLVMImport.cpp
135

This point is only reachable if the dialect interface does not implement a handler for a metadata kind that it is supposed to support (i.e., a metadata kind returned by getSupportedMetadata. If we reach this point we thus face an implementation error and not an input program dependent error.

I added a comment to clarify this.

ftynse accepted this revision.Dec 28 2022, 5:12 AM
ftynse added inline comments.
mlir/include/mlir/Dialect/LLVMIR/LLVMIntrinsicOps.td
183–184

This feels repetitive. Can't we automate this a bit? Not sure if we need this for all ops or a subset... In the latter case, may be have an extra tablegen field bit builderSetsDebugMetadata defaulted to false.

mlir/include/mlir/Target/LLVMIR/LLVMImportInterface.h
69

Please document what the returned list of integers contains.

128–130

Nit: explain what happens if only a subset of conversions succeed.

135

Nit: I'd use an find and iterators to avoid copying the vector (one can get a reference to the stored value from the iterator, but not from lookup AFAIR).

161

This is a legitimate use case for something like SmallVector<Dialect *, 1>.

mlir/lib/Target/LLVMIR/Dialect/LLVMIR/LLVMIRToLLVMImport.cpp
102

IMO, it's fine without an interface here. LLVM IR is a closed set of operations and there aren't that many that support branch weights to justify the complexity of an extra interface.

This revision is now accepted and ready to land.Dec 28 2022, 5:12 AM
gysit updated this revision to Diff 485760.Dec 31 2022, 2:47 AM
gysit marked 5 inline comments as done.

Address first batch of review comments.

gysit updated this revision to Diff 485762.Dec 31 2022, 3:03 AM

Fix merging mishap and rename metadata.ll to profiling-metadata.ll

gysit updated this revision to Diff 485855.Jan 2 2023, 3:24 AM

Address automation review comment (avoid repetitive setNonDebugMetadataAttrs calls).

gysit added inline comments.Jan 2 2023, 3:27 AM
mlir/include/mlir/Dialect/LLVMIR/LLVMIntrinsicOps.td
183–184

I tried to automate it by maintaining an additional noResultOpMapping in the ModuleImport. It maps LLVM IR instructions that have no result to the corresponding MLIR operation. The setNonDebugMetadataAttrs method can then be called from within the ModuleImport and the tablegen files only need minor changes to store the newly created operations that return no result.

An alternative could be to call setNonDebugMetadataAttrs only on a per need basis (so initially only on controlflow operations). However, I think the set of operations that require a metadata import will grow quickly and certain metadata may live on all operations (e.g., !annotation). I thus prefer a solution that supports all operations from the beginning.

gysit updated this revision to Diff 485942.Jan 3 2023, 1:54 AM

Emit a warning if an operation is dropped during the import instead of asserting and add a test case.

Dinistro accepted this revision.Jan 3 2023, 3:42 AM

LGTM!

This revision was automatically updated to reflect the committed changes.