[all-commits] [llvm/llvm-project] f117bb: [mlir] Add opt-in default property bytecode read a...

[Markus Böck via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f117bbca041c9b0c59002835d939e1bc9e76cf39
      https://github.com/llvm/llvm-project/commit/f117bbca041c9b0c59002835d939e1bc9e76cf39
  Author: Markus Böck <markus.boeck02 at gmail.com>
  Date:   2023-07-21 (Fri, 21 Jul 2023)

  Changed paths:
    M mlir/include/mlir/IR/OpBase.td
    A mlir/test/IR/properties-bytecode-roundtrip.mlir
    M mlir/test/lib/Dialect/Test/TestOps.td
    M mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp

  Log Message:
  -----------
  [mlir] Add opt-in default property bytecode read and write implementation

Using properties currently requires at the very least implementing four methods/code snippets:
* `convertToAttribute`
* `convertFromAttribute`
* `writeToMlirBytecode`
* `readFromMlirBytecode`

This makes replacing attributes with properties harder than it has to be: Attributes by default do not require immediately defining custom bytecode encoding.

This patch therefore adds opt-in implementations of `writeToMlirBytecode` and `readFromMlirBytecode` that work with the default implementations of `convertToAttribute` and `convertFromAttribute`. They are provided by `defvar`s in `OpBase.td` and can be used by adding:
```
let writeToMlirBytecode = writeMlirBytecodeWithConvertToAttribute;
let readFromMlirBytecode = readMlirBytecodeUsingConvertFromAttribute;
```
to ones TableGen definition.

While this bytecode encoding is almost certainly not ideal for a given property, it allows more incremental use of properties and getting something sane working before optimizing the bytecode format.

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


  Commit: 822c31a0fe827a6f33601ad6b44eb2818350da36
      https://github.com/llvm/llvm-project/commit/822c31a0fe827a6f33601ad6b44eb2818350da36
  Author: Markus Böck <markus.boeck02 at gmail.com>
  Date:   2023-07-21 (Fri, 21 Jul 2023)

  Changed paths:
    M llvm/cmake/config-ix.cmake
    M llvm/include/llvm/Config/config.h.cmake
    M llvm/tools/llvm-exegesis/lib/BenchmarkRunner.cpp

  Log Message:
  -----------
  [llvm-exegesis] Guard `__builtin_thread_pointer` behind a configure check

Due to arguably a bug in GCC[0], using `__has_builtin` is not sufficient to check whether `__builtin_thread_pointer` can actually be compiled by GCC. This makes it impossible to compile LLVM with `llvm-exegesis` enabled with e.g. GCC 10 as it does have the builtin, but no implementation for architectures such as x86.

This patch works around this issue by making it a cmake configure check whether the builtin can be compiled and used, rather than relying on the broken preprocessor macro.

[0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96952, demonstration: https://godbolt.org/z/9z5nWM6Ef

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


Compare: https://github.com/llvm/llvm-project/compare/ede20c1e690b...822c31a0fe82