llvm-project

05bd2d91 - [mlir] Switch to llvm::cast in generated Op::create() definitions (#217845)

[mlir] Switch to llvm::cast in generated Op::create() definitions (#217845) Switch from llvm::dyn_cast() to llvm::cast() in the TableGen-generated code for Op::create() syntax. Repeat the same for the deprecated OpBuilder::create(). From the code, it seems the intent was always to unconditionally convert an abstract operation to a specified operation type. Yet, since llvm::dyn_cast() is used to perform the conversion, it practically means that, even in release builds, there's a branch generated for the case if such conversion fails. This is likely a minuscule problem at a single operation level but perhaps somewhat affects the overall performance of the compiler when the number of operations is high (e.g. consider instruction cache). It looks like what one can do instead is change llvm::dyn_cast() to llvm::cast() and keep the nice assert-based failure check via llvm::isa(). Behaviour-wise, in case of failure, dyn_cast would produce a nullptr, dereferencing which is UB. Now, cast would likely produce a malformed object which is slightly worse but still technically UB. That is, in both cases the main expectation is that creation succeeds, and if it fails, the user is probably going to see the UB. Disclaimer: no performance measurements were done to back up the claim of dyn_cast being worse than cast.