- User Since
- Jun 28 2018, 2:24 AM (204 w, 1 d)
Wed, May 25
Mon, May 23
Fri, May 20
Thu, May 19
Wed, May 18
Nit: could you please update the commit message to specify the translation _from LLVM IR_. Otherwise, it may trick a casual reader into thinking that we haven't supported translating simple instructions _to LLVM IR_ until this point.
I am not very convinced by the motivation of LLVM backend selecting the appropriate instructions. On other platforms, we have repeatedly seen the selection being fragile and sensitive to factors beyond our control, so I would rather have the possibility to target these directly even if it is not being used by some compilations pipelnes.
Tue, May 17
This will not happen for a random class that does not have CastInfo specialized though. For Operation *, the compiler picks the CastInfo<T, ::mlir::Operation *> specialization over the more generic CastInfo<T, T>, I don't think there is an easy way around this.
The minimal example is
Mon, May 16
Fri, May 13
Thu, May 12
Nice, thank you!
Could you please reference the commit that changed the function name in the description of this commit?
Fri, May 6
Since reshape ops don't have offsets, sizes, or strides, this
patch simply sets the allocated and aligned pointers of the MemRef
I'm incline to rewrite the algorithm used in GEPOp::findKnownStructIndices (and recordStructIndices) to adopt the better solution I mentioned previously.
Wed, May 4
Thanks, something might be off with the check, but I'm not sure I agree with your current assessment. The verifier does recurse into structs - https://github.com/llvm/llvm-project/blob/ff8d0b338f48ab26919ac84aef2c79e1e1a20ef2/mlir/lib/Dialect/LLVMIR/IR/LLVMDialect.cpp#L406-L429. My another suspicion is that build methods are not matching your expectation, it would be helpful to have a MLIR-only test that demonstrates the problem by parsing IR, rather than building it (use the generic form to bypass parser checks). If this proves impossible, the issue is in the build method.
Tue, May 3
Mon, May 2
This is indeed sad, but seemed like least worst solution compared to enable_if.
Fri, Apr 29
Please add tests for user-visible error messages.
The complexity of the test is scary. Is it just a matter of having a sufficient amount of instructions and/or constants in a vector?
Thu, Apr 28
Apr 27 2022
Apr 26 2022
Yes, it will be required. b84f95fe5348ac97d33ffd2f6845b7f1b17b389c should silence the warning.
Any reason to restrict num_threads to be 32-bit specifically? The spec says it must evaluate to a positive integer value, nothing about its size. I would rather keep it as AnyInteger, and maybe even allowed Index.
Nice catch, thanks!
I edited the description a bit. Please also note that phabricator-style markup (e.g., using // for italic) looks weird in git commit messages (e.g., C-style comment).
Nice, thank you!
Apr 25 2022
We should add a facility (a pass presumably) that hoists allocas up to some user-specified level. Maybe the allocation scope that is not nested in another allocation scope, but is nested in the closest isolated-from-above operation. I believe @wsmoses has a prototype for this.
Apr 22 2022
Thanks for the cleanup!
Apr 21 2022
Try fixing Windows.
Apr 20 2022