Update LLVM version, 2025 Q4

[rniczh]

Context:

Update llvm, stablehlo and enzyme, 2025 Q4
The latest pair of good versions, indicated by stablehlo, is openxla/stablehlo@0a4440a

stablehlo=0a4440a5c8de45c4f9649bf3eb4913bf3f97da0d
llvm=113f01aa82d055410f22a9d03b3468fa68600589

For Enzyme, we go to the latest release https://github.com/EnzymeAD/Enzyme/releases/tag/v0.0.203

enzyme=v0.0.203

with commit 476c8e3193a8577ba24ff845ae2294109225f83a

Description of the Change:

• llvm-project/mlir/include/mlir/InitAllPasses.h header no longer includes individual pass headers.
  To incorporate specific passes, you now need to include either mlir/Conversion/Passes.h or the header for each dialect pass. This change stems from the upstream cleanup of mlir/InitAllDialects.h, which previously handled these includes. Following the decision from the owner (as seen in this pull request comment: https://github.com/ftynse/water/pull/16/files#r2259526343), we will specifically include each required header, faster compilation (no unnecessary headers). For further context, refer to this PR: [mlir] Reland Move InitAll*** implementation into static library llvm/llvm-project#151150
• To bufferize custom tensors into custom buffers. The upstream PR [mlir][bufferization] Return BufferLikeType in BufferizableOpInterface llvm/llvm-project#144867 changed the the return type of bufferization::detail::defaultGetBufferType to be BufferLikeType instead of BaseMemRefType. We aligned the behaviour with the upstream PR, return the BufferLikeType from our getBufferType() implementation as well.
• elemwise_unary and elemwise_binary of linalg have been deprecated from the upstream, replaced with elementwise. [MLIR][Linalg] Remove elemwise_unary and elemwise_binary llvm/llvm-project#147082. Follow this PR, using linalg.add directly.
  register_all_dialects/passes/extension` should now be configured as a static library in CMake, refer to this PR: [mlir] Reland Move InitAll*** implementation into static library llvm/llvm-project#151150
• An opt-in feature ({op}::create method) be added to support the same behaviour of rewriter.create method. But it provides a meaningful message when using this new opt-in feature compared to rewrite.create. Since the new generated create function will call the build function, it requires us to define the instance of the builder (GraidentOps.td). Refer to the PR: [mlir][tblgen] add concrete create methods llvm/llvm-project#147168.
  Take linalg.abs as an example:

  void AbsOp::build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ValueRange inputs, ValueRange outputs, ArrayRef<NamedAttribute> attributes) {
         buildStructuredOp(odsBuilder, odsState, std::nullopt, inputs, outputs,
           attributes, AbsOp::getRegionBuilder());
      
  }
  
  AbsOp AbsOp::create(::mlir::OpBuilder &builder, ::mlir::Location location, ValueRange inputs, ValueRange outputs, ArrayRef<NamedAttribute> attributes) {
   ::mlir::OperationState __state__(location, getOperationName());
   build(builder, __state__, inputs, outputs, attributes);
   auto __res__ = ::llvm::dyn_cast<AbsOp>(builder.create(__state__));
   assert(__res__ && "builder didn't return the right type");
   return __res__;
  }
  
  AbsOp AbsOp::create(::mlir::ImplicitLocOpBuilder &builder, ValueRange inputs, ValueRange outputs, ArrayRef<NamedAttribute> attributes) {
   return create(builder, builder.getLoc(), inputs, outputs, attributes);
  }

• Changed EnzymeStatic-21 to EnzymeStatic-22

TODO:

• Update .dep_version
• Change all rewrite.create to {op}::create
  Even it’s compatible to the current rewrite.create method, we don’t need to change all rewrite.create to {op}::create right away, but this new feature provides more friendly development experience. Just for an example: [mlir][core] NFC update builder create API usage llvm/llvm-project#147311

Benefits:

Possible Drawbacks:

Related GitHub Issues:
[sc-100911]
[sc-100912]