[all-commits] [llvm/llvm-project] e67080: [mlir][ods] Populate properties in generated build...

[Jacques Pienaar via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e67080df999c035d764c42aaa6d85417331ac52c
      https://github.com/llvm/llvm-project/commit/e67080df999c035d764c42aaa6d85417331ac52c
  Author: Jacques Pienaar <jpienaar at google.com>
  Date:   2024-05-15 (Wed, 15 May 2024)

  Changed paths:
    M mlir/include/mlir/Dialect/LLVMIR/LLVMOps.td
    M mlir/include/mlir/Dialect/MemRef/IR/MemRefOps.td
    M mlir/include/mlir/Dialect/Tensor/IR/TensorOps.td
    M mlir/include/mlir/IR/Operation.h
    M mlir/lib/Dialect/Func/Transforms/OneToNFuncConversions.cpp
    M mlir/lib/Dialect/MemRef/IR/MemRefOps.cpp
    M mlir/lib/Dialect/Tensor/IR/TensorOps.cpp
    M mlir/test/Dialect/OpenMP/invalid.mlir
    M mlir/test/Dialect/OpenMP/ops.mlir
    M mlir/test/lib/Dialect/Test/TestOps.td
    M mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
    M mlir/unittests/TableGen/OpBuildGen.cpp

  Log Message:
  -----------
  [mlir][ods] Populate properties in generated builder (#90430)

Previously this was only populated in the create method later. This
resolves some of invalid builder paths. This may also be sufficient that
type inference functions no longer have to consider whether property
conversion has happened (but haven't verified that yet).

This also makes Attributes corresponding to Properties as optional
inside the set from attributes method. Today that is in effect what
happens with Property value initialization and folks use it to define
custom C++ types whose default initialization is what they want. This is
the behavior users get if they use properties directly. Propagating
Attributes without allowing partial setting would require iterating over
the dictionary attribute considering the properties of the op type that
will be created. This could also have been an additional method
generated or optional behavior on the set method. But doing it
consistently seems better. In terms of whats lost, it doesn't seem like
anything compared to the pure Property path where Property is default
value initialized and then partially overwritten (this doesn't seem to
buy anything else verification wise).

Default valued Properties (as specified ODS side rather than C++ side)
triggered error as the containing class was not yet complete but
referenced nested class, so that we couldn't have default initializer
for them in the parent class. Added an additional forwarding builder to
avoid needing to update call sites. This could be split out to separate
change.

Inlined templated function in unit test that was only used once. Moved
initialization earlier where seen.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications