Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Conversion/GPUCommon/GPUToLLVMConversion.cpp | ||
---|---|---|
1261 | Seeking ways for easier-to-read literal comparison |
mlir/lib/Conversion/GPUCommon/GPUToLLVMConversion.cpp | ||
---|---|---|
1261 | You should be able to perform the compare without type conversion. It is essentially a pointer comparison and they will share the same underlying storage if they are equal. |
mlir/lib/Conversion/GPUCommon/GPUToLLVMConversion.cpp | ||
---|---|---|
1259–1264 | It would be cleaner to just call getConstantIntValue once and save the results. I've attached an edit to show what I mean. (Though really, there's not a whole lot of benefit to the dw_ variable, so you might as well just use *dw directly wherever needed) Though really this whole pattern should be floated out to a helper function, including the parts that check *dw and return the corresponding FloatType— since the only difference between the version here and the version for mgpuCreateCOO is which op.getOperand is used. | |
1288 | Since gpu::CreateDnMatOp::getMemref returns a TypedValue<MemRefType>, the TypedValue<MemRefType>::getType method will already return a MemRefType, therefore you don't need the llvm::cast | |
1294–1303 | This is yet another place that uses the same function for converting a Value (which has LLVM::ConstantOp defining op) into the appropriate FloatType... | |
1338–1339 | You can replace this with just computeTypeOptional.value_or(defaultType) https://en.cppreference.com/w/cpp/utility/optional/value_or |
mlir/lib/Conversion/GPUCommon/GPUToLLVMConversion.cpp | ||
---|---|---|
1256–1257 | I don't think you need it (same below for getDnxxx) |
mlir/lib/Conversion/GPUCommon/GPUToLLVMConversion.cpp | ||
---|---|---|
1261 | I wish I could have known it earlier. Thank you! |
mlir/lib/Conversion/GPUCommon/GPUToLLVMConversion.cpp | ||
---|---|---|
1327–1328 | Good catch! Addressed in new commit |
mlir/include/mlir/Dialect/GPU/IR/GPUOps.td | ||
---|---|---|
1913 | make this Examples and add an op below that has a compute type set | |
2000 | given the mix of return types and other types, an "into" feels a bit nicer for compute type. | |
mlir/lib/Conversion/GPUCommon/GPUToLLVMConversion.cpp | ||
692 | Start with capital C and end with period | |
mlir/lib/ExecutionEngine/CudaRuntimeWrappers.cpp | ||
308 | this TODO is done, right? |
mlir/lib/ExecutionEngine/CudaRuntimeWrappers.cpp | ||
---|---|---|
308 | Good catch. Thanks! |
mlir/lib/Conversion/GPUCommon/GPUToLLVMConversion.cpp | ||
---|---|---|
695 | Here and Below: Do you think it is better to copy the CUSPARSE macro to the file (but probably adding some prefix) so that it can be updated more easily later? Or does the current way already follows the same convention in the file? |
mlir/lib/Conversion/GPUCommon/GPUToLLVMConversion.cpp | ||
---|---|---|
695 | It is kind of the reverse. Here we map types to integers, but in the cuda header files these enum class definitions are essentially mapping types to an integer, I.e., assigning an integer to each enum item. You raise a good point that we need to have better way to keep in sync, though the CUDA headers seem to keep the mapping of already existing types the same when adding new types probably as a way to keep backward compatibility. I will need to think about how to do that in the future. |
ah, good catch on this typo!