@@ -218,6 +218,23 @@ def XeGPU_CreateNdDescOp: XeGPU_Op<"create_nd_tdesc", [Pure, ViewLikeOpInterface
218218 static unsigned getOffsetSizeAndStrideStartOperandIndex() { return 1; }
219219
220220 mlir::Value getViewSource() { return getSource(); }
221+
222+ unsigned getSourceMemorySpace() {
223+ auto srcTy = getSourceType();
224+ if (auto memrefTy = llvm::dyn_cast<mlir::MemRefType>(srcTy)) {
225+ auto attr = memrefTy.getMemorySpace();
226+ if (attr) {
227+ if (auto intAttr = llvm::dyn_cast<mlir::IntegerAttr>(attr)) {
228+ return static_cast<unsigned>(intAttr.getInt());
229+ }
230+ if (auto memSpaceAttr = llvm::dyn_cast<MemorySpaceAttr>(attr))
231+ return static_cast<unsigned>(memSpaceAttr.getValue());
232+ }
233+ }
234+ // take global as default memory scope.
235+ return static_cast<unsigned>(MemorySpace::Global);
236+ }
237+
221238 }];
222239}
223240
@@ -411,8 +428,10 @@ def XeGPU_CreateDescOp: XeGPU_Op<"create_tdesc", [Pure, ViewLikeOpInterface]> {
411428 is fixed to the hardware supportted subgroup size, e.g., 16 on PVC,
412429 implying each element in the array corresponds to a work-item (SIMT lane)
413430 in the subgroup.
414- * chunk_size: [optional attribute] indicates number of continious
415- elements accessed for each offset, default is 1.
431+
432+ The first dimension of the result TensorDesc corresponds to work-items, so it should
433+ match the dimension of offsets. It may also has a second dimension corresponding to
434+ the chunk_size if the chunk size is larger than 1.
416435
417436 Example 1. It assumes subgroup size is 4, and accesses a[0], a[16], a[32], a[64]
418437 ```mlir
@@ -424,29 +443,22 @@ def XeGPU_CreateDescOp: XeGPU_Op<"create_tdesc", [Pure, ViewLikeOpInterface]> {
424443 It will access totally 32 data elements: a[0:7], a[16:23], a[32:39], a[64:71]
425444 ```mlir
426445 %0 = memref.alloc() : memref<1024xf32>
427- %1 = xegpu.create_tdesc %0[0, 16, 32, 64] {chunk_size = 8} : memref<1024xf32> -> TensorDesc<4x8xf32>
446+ %1 = xegpu.create_tdesc %0[0, 16, 32, 64] : memref<1024xf32> -> TensorDesc<4x8xf32, chunk_size = 8 >
428447 ```
429448
430449 Example 3. It is similar to Example 2, but there is some overlaps among workitems.
431450 It accesses: a[0:7], a[4:11], a[8:15], a[12:19]
432451 ```mlir
433452 %0 = memref.alloc() : memref<1024xf32>
434- %1 = xegpu.create_tdesc %0[0, 4, 8, 12] {chunk_size = 8} : memref<1024xf32> -> TensorDesc<4x8xf32>
453+ %1 = xegpu.create_tdesc %0[0, 4, 8, 12] : memref<1024xf32> -> TensorDesc<4x8xf32, chunk_size = 8> >
435454 ```
436455 }];
437456
438457 let arguments = (ins XeGPU_BaseAddrType: $source,
439458 Variadic<Index>: $offsets,
440- DenseI64ArrayAttr: $const_offsets,
441- DefaultValuedAttr<I64Attr, "1">: $chunk_size);
459+ DenseI64ArrayAttr: $const_offsets);
442460 let results = (outs XeGPU_TensorDesc:$TensorDesc);
443461
444- let builders = [
445- OpBuilder<(ins "xegpu::TensorDescType": $TensorDesc, "Value": $source,
446- "llvm::ArrayRef<OpFoldResult>": $offsets,
447- CArg<"uint32_t", "1"> : $chunk_size)>,
448- ];
449-
450462 let assemblyFormat = [{
451463 $source
452464 custom<DynamicIndexList>($offsets, $const_offsets)
@@ -473,6 +485,22 @@ def XeGPU_CreateDescOp: XeGPU_Op<"create_tdesc", [Pure, ViewLikeOpInterface]> {
473485 assert(idx < getNumOffsets() && "Invalid out of bound access.");
474486 return getMixedOffsets()[idx];
475487 }
488+
489+ unsigned getSourceMemorySpace() {
490+ auto srcTy = getSource().getType();
491+ if (auto memrefTy = llvm::dyn_cast<mlir::MemRefType>(srcTy)) {
492+ auto attr = memrefTy.getMemorySpace();
493+ if (attr) {
494+ if (auto intAttr = llvm::dyn_cast<mlir::IntegerAttr>(attr))
495+ return static_cast<unsigned>(intAttr.getInt());
496+ if (auto memSpaceAttr = llvm::dyn_cast<MemorySpaceAttr>(attr))
497+ return static_cast<unsigned>(memSpaceAttr.getValue());
498+ }
499+ }
500+ // take global as default memory scope.
501+ return static_cast<unsigned>(MemorySpace::Global);
502+ }
503+
476504 }];
477505
478506 let hasVerifier = 1;
@@ -520,28 +548,31 @@ def XeGPU_LoadGatherOp : XeGPU_Op<"load", [AllRanksMatch<["value", "TensorDesc"]
520548
521549 let description = [{ It (aka. load) load data per each work-item. The output
522550 describes the data being loaded at the subgroup level, so its size is
523- consistent with the number of work-items in a subgroup. When `chunk_size_per_lane`
524- attribute is larger than 1 in TensorDesc, the output vector will be 2D vector,
525- with dim-1 correspoding to the chunk size.
551+ consistent with the number of work-items in a subgroup. When the chunk size
552+ is larger than 2, the output vector is a 2D vector, with dim-1 correspoding
553+ to work-items, and dim-0 corresponding to the chunk_size loaded by each work-item.
554+ Specially, there is a transpose effect on the result (as compared to the TensorDesc)
555+ due to the hardware implementation. Therefore, a transpose attribute is introduced
556+ on purpose, making sure users are aware of this implicit transformation.
526557
527558 The mask operand masks out memory access so that it is safe to pass out-of-boundary
528559 addresses/offsets as long as they are masked. It applies to slots of SIMD lanes.
529560
530561 Example:
531562 ```mlir
532- %2 = xegpu.load %1, %0 {transpose = [1, 0] ,
563+ %2 = xegpu.load %1, %0 {transpose,
533564 l1_hint = #xegpu.cache_hint<cached>,
534565 l2_hint = #xegpu.cache_hint<uncached>,
535566 l3_hint = #xegpu.cache_hint<uncached>}
536- : !xegpu.tensor_desc<16xf32, #xegpu.tdesc_attr<scattered=true >>, vector<16xi1>
537- -> vector<16xf32>
567+ : !xegpu.tensor_desc<16xf32, #xegpu.scatter_tdesc_attr<memory_space=global >>,
568+ vector<16xi1> -> vector<16xf32>
538569 ```
539570
540571 }];
541572
542573 let arguments = (ins XeGPU_TensorDesc: $TensorDesc,
543574 XeGPU_MaskType: $mask,
544- OptionalAttr<DenseI64ArrayAttr >: $transpose,
575+ OptionalAttr<UnitAttr >: $transpose,
545576 OptionalAttr<XeGPU_CacheHintAttr>: $l1_hint,
546577 OptionalAttr<XeGPU_CacheHintAttr>: $l2_hint,
547578 OptionalAttr<XeGPU_CacheHintAttr>: $l3_hint);
@@ -573,11 +604,15 @@ def XeGPU_LoadGatherOp : XeGPU_Op<"load", [AllRanksMatch<["value", "TensorDesc"]
573604 let hasVerifier = 1;
574605}
575606
576- def XeGPU_StoreScatterOp : XeGPU_Op<"store", [AllShapesMatch <["value", "TensorDesc"]>,
577- AllElementTypesMatch<["value", "TensorDesc"]>]> {
607+ def XeGPU_StoreScatterOp : XeGPU_Op<"store", [AllElementCountsMatch <["value", "TensorDesc"]>,
608+ AllElementTypesMatch<["value", "TensorDesc"]>]> {
578609 let summary = "store data to scattered memory locations.";
579- let description = [{ It (aka. store) stores data to scattered memory locations.
580- It has similar semantic to `load_gather`.
610+ let description = [{ It (aka. store) stores data to scattered memory locations. The value is
611+ typically a 1D vector. But when the chunk size of the TensorDesc is larger than 1, it will be
612+ a 2D vector instead. For the later case, dim-1 of the value correspods to the simd lanes
613+ and the dim-0 of the value corresponds to the chunk_size stored per lane. So `store_scatter`
614+ has transpose effect, which is similar to `load_gather`. Therefore, a transpose attribute is
615+ introduced on purpose, making sure users are aware of this implicit transformation.
581616
582617 Example:
583618 ```mlir
@@ -592,6 +627,7 @@ def XeGPU_StoreScatterOp : XeGPU_Op<"store", [AllShapesMatch<["value", "TensorDe
592627 XeGPU_ValueType: $value,
593628 XeGPU_TensorDesc: $TensorDesc,
594629 XeGPU_MaskType: $mask,
630+ OptionalAttr<UnitAttr>: $transpose,
595631 OptionalAttr<XeGPU_CacheHintAttr>: $l1_hint,
596632 OptionalAttr<XeGPU_CacheHintAttr>: $l2_hint,
597633 OptionalAttr<XeGPU_CacheHintAttr>: $l3_hint);
@@ -723,7 +759,7 @@ def XeGPU_DpasOp : XeGPU_Op<"dpas", [Pure, AllElementTypesMatch<["lhs", "rhs"]>]
723759
724760def XeGPU_AtomicRMWOp: XeGPU_Op<"atomic_rmw", [Pure,
725761 AllElementTypesMatch<["tensorDesc", "value", "result"]>,
726- AllShapesMatch<["tensorDesc", "mask", " value", "result"]>]> {
762+ AllShapesMatch<["tensorDesc", "value", "result"]>]> {
727763 let summary = "Atomic ready-modify-write operation on the TensorDesc. ";
728764
729765 let description = [{
@@ -808,7 +844,7 @@ def XeGPU_FenceOp: XeGPU_Op<"fence", []> {
808844 2. `Fence_scope` describes the scope of fence. "Workgroup" means that the scope would be
809845 within each workgroup. "GPU" means the scope would be across workgroups within the GPU.
810846 }];
811- let arguments = (ins XeGPU_MemoryScopeAttr : $memory_kind,
847+ let arguments = (ins XeGPU_MemorySpaceAttr : $memory_kind,
812848 XeGPU_FenceScopeAttr: $fence_scope);
813849 let assemblyFormat = [{`memory_kind` `=` `` $memory_kind `,` `fence_scope` `=` `` $fence_scope attr-dict}];
814850 let extraClassDeclaration = extraBaseClassDeclaration;
0 commit comments