Replace the uses of deprecated Structured Op Interface methods in Promotion.cpp. This patch is based on https://reviews.llvm.org/D103394.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Dialect/Linalg/Transforms/Promotion.cpp | ||
---|---|---|
335 | Since operandNumber is already an int64_t, this cast is unnecessary. |
I would not consider this an NFC and I think the title should be updated to not include the NFC designation. It might not be changing the intended functionality, but it is changing the logic (and functions called) to achieve the result.
mlir/lib/Dialect/Linalg/Transforms/Promotion.cpp | ||
---|---|---|
327 | I thought getOperandNumber returned an unsigned? I would expect assigning an unsigned value to an int64_t to generate a warning. |
mlir/lib/Dialect/Linalg/Transforms/Promotion.cpp | ||
---|---|---|
327 | I will check if there is an error but I believe the cast happens implicitly here: c.f. "The compiler doesn't warn about implicit conversions between signed and unsigned integral types." taken from https://docs.microsoft.com/en-us/cpp/cpp/type-conversions-and-type-safety-modern-cpp?view=msvc-160 | |
335 | Thanks for the hint! |
mlir/lib/Dialect/Linalg/Transforms/Promotion.cpp | ||
---|---|---|
327 | The Visual Studio compiler, clang and gcc often behave very differently and raise different warnings. They are also all supported by llvm/mlir/etc. Generally, though, the expectation is that the code will be warning-free when building with clang, so I would recommend trying that to see if there are any warnings. |
I thought getOperandNumber returned an unsigned? I would expect assigning an unsigned value to an int64_t to generate a warning.