[all-commits] [llvm/llvm-project] 65c990: [mlir][ods] Enable emitting getter/setter prefix

[Jacques Pienaar via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 65c9907c809a275e57bd925d1eda5a743a462d20
      https://github.com/llvm/llvm-project/commit/65c9907c809a275e57bd925d1eda5a743a462d20
  Author: Jacques Pienaar <jpienaar at google.com>
  Date:   2021-10-14 (Thu, 14 Oct 2021)

  Changed paths:
    M mlir/include/mlir/IR/OpBase.td
    M mlir/include/mlir/TableGen/Dialect.h
    M mlir/lib/TableGen/Dialect.cpp
    M mlir/test/mlir-tblgen/op-attribute.td
    M mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp

  Log Message:
  -----------
  [mlir][ods] Enable emitting getter/setter prefix

Allow emitting get & set prefix for accessors generated for ops. If
enabled, then the argument/return/region name gets converted from
snake_case to UpperCamel and prefix added. The attribute also allows
generating both the current "raw" method along with the prefix'd one to
make it easier to stage changes.

The option is added on the dialect and currently defaults to existing
raw behavior. The expectation is that the staging where both are
generated would be short lived and so optimized to keeping the changes
local/less invasive (it just generates two functions for each accessor
with the same body - most of these internally again call a helper
function). But generation can be optimized if needed.

I'm unsure about OpAdaptor classes as there it is all get methods (it is
a named view into raw data structures), so prefix doesn't add much.

This starts with emitting raw-only form (as current behavior) as
default, then one can opt-in to raw & prefixed, then just prefixed. The
default in OpBase will switch to prefixed-only to be consistent with
MLIR style guide. And the option potentially removed later (considered
enabling specifying prefix but current discussion more pro keeping it
limited and stuck with that).

Also add more explicit checking for pruned functions to avoid emitting
where no function was added (and so avoiding dereferencing nullptr)
during op def/decl generation.

See https://bugs.llvm.org/show_bug.cgi?id=51916 for further discussion.

Differential Revision: https://reviews.llvm.org/D111033