This is an archive of the discontinued LLVM Phabricator instance.

[mlir][llvm] Add structured loop metadata
ClosedPublic

Authored by Dinistro on Feb 1 2023, 5:46 AM.

Details

Summary

This commit introduces a structured representation of loop metadata to
the LLVM dialect. This attribute explicitly models all known !llvm.loop
metadata fields and groups them by introducing nested attributes for each
namespace.

The new attribute replaces the LoopOptionAttr that could only model a
limited subset of loop metadata.

Diff Detail

Event Timeline

Dinistro created this revision.Feb 1 2023, 5:46 AM
Herald added a project: Restricted Project. · View Herald Transcript
Dinistro requested review of this revision.Feb 1 2023, 5:46 AM
gysit added inline comments.Feb 1 2023, 7:19 AM
mlir/include/mlir/Dialect/LLVMIR/LLVMAttrDefs.td
52

nit: It is actually multiple attributes. What about "Loop Attributes".

55

nit: What about replacing OptionsAttr -> with Attr only? That makes the name a bit shorter and we could use "LoopVectorize", "loop_vectorize" as class and attribute name (similar to the debug info).

57–58

nit: Annotation may be a better fit it we do the renaming below.

This attribute defines vectorization specific loop annotations that map to the "!llvm.loop.vectorize" metadata.

170

nit: I would probably drop metadata in favor of Annotations or nothing:

def LoopAnnotationsAttr : LLVM_Attr<"LoopAnnotations", "loop_annotations"> {

mlir/lib/Dialect/LLVMIR/IR/LLVMDialect.cpp
3000–3016

nit: annotation if we do the renaming.

mlir/lib/Target/LLVMIR/Dialect/LLVMIR/LLVMToLLVMIRTranslation.cpp
170

Would it be worth factoring this out in a separate file similar to DebugTransation.cpp / DebugTranslation.h?

Dinistro updated this revision to Diff 493953.Feb 1 2023, 8:03 AM
Dinistro marked 5 inline comments as done.

Address the renaming comments

Dinistro updated this revision to Diff 493971.Feb 1 2023, 8:36 AM

move into separate files and dispatch through ModuleTranslation

Dinistro marked an inline comment as done.Feb 1 2023, 8:36 AM
Dinistro updated this revision to Diff 494183.Feb 2 2023, 12:19 AM

refactoring of the conversion class

gysit added inline comments.Feb 2 2023, 2:02 AM
mlir/lib/Target/LLVMIR/LoopAnnotationTranslation.h
26

nit: Let's call this LoopAnnotationTranslation similar to the DebugTranslation and similar to the file name.

35

Would it make sense to pass the LoopAnnotationAttr and the opInst as parameters to the convert method. IMO that may make interface a bit clearer and the class could potentially be reused for multiple translations? It may be even worth considering moving the mapping from attribute to the translated metadata into this class?

38–39

ultra nit: Conversion functions for different payload attribute kinds.

46–47

ultra nit: for each loop annotation sub-attribute.

60

ultra nit: mdNodes -> metadataNodes?

Dinistro updated this revision to Diff 494254.Feb 2 2023, 4:24 AM
Dinistro marked 5 inline comments as done.

address additional review comments

gysit accepted this revision.Feb 2 2023, 4:28 AM

nice! LGTM!

This revision is now accepted and ready to land.Feb 2 2023, 4:28 AM
This revision was automatically updated to reflect the committed changes.
gflegar added a subscriber: gflegar.Feb 3 2023, 4:55 AM
gflegar added inline comments.Feb 3 2023, 4:58 AM
mlir/include/mlir/Dialect/LLVMIR/LLVMAttrs.h
83

Any suggestions on how to get the same functionality as this class provides with the new structure?

I'm trying to integrate this change into our internal codebase, and one use case we had for this was to express "take the preexisting attribute, and just modify some of the values (based on some parameters)".
With the new change, it seem the only way to achieve the same thing is to manually spell out every single field of the nested structure whenever we need to do this.

gflegar added inline comments.Feb 3 2023, 5:03 AM
mlir/include/mlir/Dialect/LLVMIR/LLVMAttrs.h
83

In addition, this method would be quite fragile, as that code would have to be updated every time the structure changes (e.g., a new field is added).

Dinistro added inline comments.Feb 3 2023, 5:21 AM
mlir/include/mlir/Dialect/LLVMIR/LLVMAttrs.h
83

Creating a builder for all possible loop annotations requires a careful design to make it usable for general cases. If you have a limited set of properties you want to change, you could implement a builder that stores the old attribute and keeps track of changes. Only after all changes were performed, the builder can materialize them in the form of a new attribute.
As the set of changeable values can be limited, the amount of state-keeping can be reduced to a minimum.