main

文件	最后提交记录	最后更新时间
invalid.mlir	[MLIR][ArmSVE] Add an ArmSVE dialect operation mapping to bfmmla (#145064)	1 年前
legalize-for-llvm.mlir	[MLIR][ArmSVE] Add an ArmSVE dialect operation which maps to svusmmla (#135634)	1 年前
legalize-transfer-read.mlir	[mlir][vector] Avoid setting padding by default to 0 in vector.transfer_read prefer ub.poison (#146088) Context: vector.transfer_read always requires a padding value. Most of its builders take no padding value and assume the safe value of 0. However, this should be a conscious choice by the API user, as it makes it easy to introduce bugs. For example, I found several occasions while making this patch that the padding value was not getting propagated (vector.transfer_read was transformed into another vector.transfer_read). These bugs, were always caused because of constructors that don't require specifying padding. Additionally, using ub.poison as a possible default value is better, as it indicates the user "doesn't care" about the actual padding value, forcing users to specify the actual padding semantics they want. With that in mind, this patch changes the builders in vector.transfer_read to always having a std::optional<Value> padding argument. This argument is never optional, but for convenience users can pass std::nullopt, padding the transfer read with ub.poison. --------- Signed-off-by: Fabian Mora <fabian.mora-cordero@amd.com>	1 年前
legalize-vector-storage.mlir	[mlir][ArmSVE] Add -arm-sve-legalize-vector-storage pass (#68794) This patch adds a pass that ensures that loads, stores, and allocations of SVE vector types will be legal in the LLVM backend. It does this at the memref level, so this pass must be applied before lowering all the way to LLVM. This pass currently fixes two issues. ## Loading and storing predicate types It is only legal to load/store predicate types equal to (or greater than) a full predicate register, which in MLIR is vector<[16]xi1>. Smaller predicate types (vector<[1|2|4|8]xi1>) must be converted to/from a full predicate type (referred to as a svbool) before and after storing and loading respectively. This pass does this by widening allocations and inserting conversion intrinsics. For example: mlir %alloca = memref.alloca() : memref<vector<[4]xi1>> %mask = vector.constant_mask [4] : vector<[4]xi1> memref.store %mask, %alloca[] : memref<vector<[4]xi1>> %reload = memref.load %alloca[] : memref<vector<[4]xi1>> Becomes: mlir %alloca = memref.alloca() {alignment = 1 : i64} : memref<vector<[16]xi1>> %mask = vector.constant_mask [4] : vector<[4]xi1> %svbool = arm_sve.convert_to_svbool %mask : vector<[4]xi1> memref.store %svbool, %alloca[] : memref<vector<[16]xi1>> %reload_svbool = memref.load %alloca[] : memref<vector<[16]xi1>> %reload = arm_sve.convert_from_svbool %reload_svbool : vector<[4]xi1> ## Relax alignments for SVE vector allocas The storage for SVE vector types only needs to have an alignment that matches the element type (for example 4 byte alignment for f32s). However, the LLVM backend currently defaults to aligning to base size x element size bytes. For non-legal vector types like vector<[8]xf32> this results in 8 x 4 = 32-byte alignment, but the backend only supports up to 16-byte alignment for SVE vectors on the stack. Explicitly setting a smaller alignment prevents this issue. Depends on: #68586 and #68695 (for testing)	2 年前
roundtrip.mlir	[MLIR][ArmSVE] Add an ArmSVE dialect operation mapping to bfmmla (#145064)	1 年前