[Mlir-commits] [mlir] [MLIR][ROCDL] Add conversion for gpu.subgroup_id to ROCDL (PR #136405)
Krzysztof Drewniak
llvmlistbot at llvm.org
Tue Apr 22 14:49:25 PDT 2025
================
@@ -80,6 +80,24 @@ static constexpr StringLiteral amdgcnDataLayout =
"64-S32-A5-G1-ni:7:8:9";
namespace {
+
+// Truncate or extend the result depending on the index bitwidth specified
+// by the LLVMTypeConverter options.
+static Value truncOrExtToLLVMType(ConversionPatternRewriter &rewriter,
+ Location loc, Value value,
+ const LLVMTypeConverter *converter) {
+ auto intWidth = cast<IntegerType>(value.getType()).getWidth();
+ auto indexBitwidth = converter->getIndexTypeBitwidth();
+ if (indexBitwidth > intWidth) {
+ return rewriter.create<LLVM::SExtOp>(
----------------
krzysz00 wrote:
I don't know. I suspect that we want `zext nneg` when we know it's equivalent - ex, on these IDs that are guaranteed to be in [0, i32_signed_max)` or some stricter range. However, there's an assumption in much of `affine` and co that `index` is signed when there's an ambiguity.
Int range optimization often creates sext/trunc pairs for these things in practice.
I suspect that for now we want `sext`for MLIR-semantic reasons and then to filter it down later in the backend, especially if we can stick a `range(i32 0, [upper bound we actually know])` on the intrinsic.
... Heck, even in the absence of the actual subgroup size, we do know said upper bound: 1024 / [wave size], aka 1024 / 32 = 32 ... which we can just hint to LLVM
(Though see also my note about how this intrinsic basically doesn't exist on any GPU of interest)
https://github.com/llvm/llvm-project/pull/136405
More information about the Mlir-commits
mailing list