The patch makes the index type lowering of the GPU to NVVM/ROCDL conversion configurable. It introduces a pass option that controls the bitwidth used when lowering index computations.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
My assumption is that the LLVMTypeConverterCustomization do not interfere with the address space conversion. Should the address space conversion be an integral part of the LLVMTypeConverterCustomization class?
This is a bit muddled at the moment but it is ok to assume this for now.
mlir/lib/Conversion/GPUToNVVM/LowerGpuOpsToNVVMOps.cpp | ||
---|---|---|
109 | Typo: bidtwidth -> bitwidth |
I fixed the typo and added extended the existing tests a little bit to test 32-bit index computations
If we want to strive to little bit bigger refactoring we can postpone landing
mlir/lib/Conversion/GPUToNVVM/LowerGpuOpsToNVVMOps.cpp | ||
---|---|---|
109 | fixed |
In the future please upload your patches with full context: https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface
The update passes the options structure to the type converter and to the conversion pattern base class (replaces the llvm type converter customizations). I also extended the patch to the rocdl backend.
The downside of the patch is that I have to pass the lower to llvm options to all the patters. Theoretically it would also be possible to access the options via the type converter but most of them are not related to the type conversion.
nn
mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h | ||
---|---|---|
385 | I am puzzled how is this working? This default value for this parameter is mapped to a reference member, how isn't it gonna lead to "use-after-free"? |
mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h | ||
---|---|---|
385 | You are right this should not work (the lifetime of the default argument is limited to the body of the constructor -- I believe). I will submit a patch to fix this problem. |
mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h | ||
---|---|---|
385 | Hmm, why wouldn't it? The lifetime of the temporary is that of the constructor body. The reference will be used to copy-construct the member struct at the beginning of the constructor implementation, at which point the temporary is guaranteed to be live. Then we will only use the member. It would have been a problem if ConvertToLLVMPattern kept a reference to the temporary. |
mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h | ||
---|---|---|
385 |
The options member is unfortunately a const reference. |
mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h | ||
---|---|---|
385 | My bad, I looked elsewhere. The reference capture semantics should be documented somewhere. Or in a more hacky way, this can accept a non-const reference that would effectively disallow passing in temporaries. |
mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h | ||
---|---|---|
385 | should we just make the options a non-reference member of ConvertToLLVMPattern? At the moment to struct is super small and copying the options should not harm performance. |
mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h | ||
---|---|---|
385 | + 1, this broke our flang builds with some compilers (they randomly emitted C interface). |
mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h | ||
---|---|---|
385 | Duplicating the option in every single pattern instance inheriting from ConvertToLLVMPattern seems a bit suboptimal to me. | |
mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVMPass.h | ||
30 | If you reorder the bool before the unsigned, the struct would be smaller I think (on most platform) |
mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h | ||
---|---|---|
385 |
Sorry for breaking your build. I reverted the commit which hopefully solves your problem. | |
385 |
Using a reference or a pointer to the options structure are possible alternatives. Both of them have memory lifetime issues if the referenced memory is freed to early. An alternative could be to pass in a callback that returns an options structure (similar to the one used for the type converter before). This solution has no lifetime issues and the memory footprint should be minimal (a function pointer). |
mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h | ||
---|---|---|
385 | I'm missing something: how is the lifetime of the callback managed? In some way if you can pass a pointer to a callback that returns the data, you can also provide a pointer to the data. |
mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h | ||
---|---|---|
385 | The idea was to use a local static variable LowerToLLVMOptions myConfigOptions() { static const LowerToLLVMOptions myOptions = { /* ... */ }; return myOptions; } However, this solution only works for the options that can be statically initialized (such as the default options) and pointers/references are still needed for the runtime pass parameters. So having pointers / references everywhere may be the better solution. |
mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h | ||
---|---|---|
385 | In particular, if you can have a static you can also pass it by reference :) |
mlir/include/mlir/Conversion/StandardToLLVM/ConvertStandardToLLVM.h | ||
---|---|---|
385 | Thanks, this part of flang code is still in a fork so it was hard for you to know. What went wrong in our builds was the default arguments. They ended-up being temps with the lifetime of the ctor call. Creating the default LowerToLLVMOptions on our side and passing it to populateStdToLLVMConversionPatterns was working OK. |
I am puzzled how is this working?
This default value for this parameter is mapped to a reference member, how isn't it gonna lead to "use-after-free"?