User Details
- User Since
- Jan 13 2020, 1:53 AM (202 w, 5 d)
Aug 30 2023
Aug 29 2023
Jul 27 2023
Thanks for updating the PR @jpienaar.
Jul 11 2023
Thanks for your review @jpienaar!
Jul 10 2023
Jul 4 2023
Jun 23 2023
May 11 2023
Could you also add tests to test/Dialect/EmitC/ops.mlir and maybe also to test/Dialect/EmitC/invalid_ops.mlir?
May 10 2023
May 9 2023
Updating D149963: [mlir][emitc] Add add and sub operations
Updating D149963: [mlir][emitc] Add add and sub operations
Updating D149963: [mlir][emitc] Add add and sub operations
May 8 2023
Updating D149963: [mlir][emitc] Add add and sub operations
May 5 2023
May 4 2023
I added myself and especially @simon-camp as reviewer, since I might be oof when this is ready for review.
Apr 27 2023
Thanks!
Apr 26 2023
Thanks for the patch! Tested locally, LGTM. Unfortunately, I have some problems with arcanist grabbing the complete patch. I will try to land it tomorrow.
Apr 18 2023
Currently no reviewers are specified. Would you like @simon-camp and me to review? We initially pushed the code and mostly maintain it.
I added @simon-camp and myself as reviewers, as we initial pushed the code and mostly maintain it. We will take a look early next week.
Mar 10 2023
As far as I see this should be fine, even though I am not 100% familiar with the exact mechanism implemented here.
Mar 1 2023
Feb 17 2023
Feb 10 2023
This was presented as part of my talk How to Build your own MLIR Dialect at FOSDEM 2023.
Thanks for driving this! We actually had something similar on our long term roadmap and think something function meta attribute like would be desirable. However, for the omp dialect there it is currently discussed on discourse if to go for an omp.function instead of a dialect attribute, see https://discourse.llvm.org/t/rfc-omp-module-and-omp-function-vs-dialect-attributes-to-encode-openmp-properties/67998. I think the same discussion applies here as well. Instead of having emitc.func_attr together with func.func we might want to have emitc.func?
This was presented as part of my talk How to Build your own MLIR Dialect at FOSDEM 2023.
Jan 30 2023
Jan 16 2023
Thanks for adding me @jpienaar and thanks @christopherbate for improving the EmitC dialect! LGTM.
Aug 12 2022
Aug 11 2022
Aug 10 2022
Aug 1 2022
Jul 28 2022
May 5 2022
I am currently out-of-office and don‘t have any access to my build machines. Therefore, I cannot test and confirm that the patch doesn‘t have unintended side effects. However, there is definitely a need to add a dependency to the tablgen generated header files. Sorry for missing this as part of https://reviews.llvm.org/D124851. I would suggest to take a look how this is done for MLIR dialects, where explicits deps to the generated targets are passed to add_mlir_dialect_library like in https://github.com/llvm/llvm-project/blob/04b419048955fc33718ba97e79f3558b6a27830e/mlir/lib/Dialect/EmitC/IR/CMakeLists.txt#L7-L9. It might not be necessary to touch AddLLVM and I assume the deps should rather be on the *IncGen target,
May 3 2022
The missing dep on MLIRIR actually showed up as a race condition in the build process on a GH runner.
Apr 28 2022
Apr 25 2022
Thanks for the review @jpienaar! I will address your comments before landing.
Updating D124002: [mlir][emitc] Disallow !emitc.opaque pointers
Apr 19 2022
Apr 13 2022
Apr 12 2022
Apr 11 2022
Mar 28 2022
Mar 23 2022
Mar 14 2022
Mar 11 2022
Please excuse if my previous reply was confusing. I checked more carefully and think these changes are good to go.
Mar 2 2022
Thanks for working on this Stella! Untangling the functions/marcos is a bit hard. Thus, I am mainly commenting to make sure I fully understand the patch :)
Feb 24 2022
Feb 23 2022
Address review comments
Feb 17 2022
As an example, the canonicalization pass would transform
func @myfunc() { %0 = "emitc.constant"() {value = 0 : i32} : () -> i32 %1 = "emitc.constant"() {value = 0 : i32} : () -> i32 %2 = emitc.apply "&"(%0) : (i32) -> !emitc.ptr<i32> %3 = emitc.apply "&"(%1) : (i32) -> !emitc.ptr<i32> emitc.call "write"(%2, %3) : (!emitc.ptr<i32>, !emitc.ptr<i32>) -> () return }
into
func @myfunc() { %0 = "emitc.constant"() {value = 0 : i32} : () -> i32 %1 = emitc.apply "&"(%0) : (i32) -> !emitc.ptr<i32> %2 = emitc.apply "&"(%0) : (i32) -> !emitc.ptr<i32> emitc.call "write"(%1, %2) : (!emitc.ptr<i32>, !emitc.ptr<i32>) -> () return }
resulting in pointer aliasing. Here, the variable op would be helpful.