User Details
- User Since
- May 5 2017, 1:55 PM (307 w, 1 d)
Fri, Mar 24
Thu, Mar 23
Looks OK.
Wed, Mar 22
Tue, Mar 21
You can test the TODOs if you want by adding tests like the following.
https://github.com/llvm/llvm-project/blob/main/flang/test/Lower/OpenMP/Todo/reduction-allocatable.f90
Mon, Mar 20
The problem with doing this in two stages : i.e during lowering and a pass are that there are two representations for the same thing in the IR. One where the nested functions are not marked, and the other where they are not marked.
Fri, Mar 17
LGTM. Please wait a day before submission. Move the flang portion to a separate commit.
Thu, Mar 16
Thanks @MatsPetersson for working on this. I have started going through the patch and have some comments.
Wed, Mar 15
@jdoerfert Would using functions from compiler-rt cause issues with target offloading?
Context: We are thinking of using functions from compiler-rt for implementing the complex division operation. The existing implementations in Flang (an inline one) and the one on MLIR both have precision issues whereas the compiler-rt ones work fine.
Tue, Mar 14
@labrinea Is this patch the top-level patch for recursive function-specialization that benefits exchange2? Is there any setting required or would this perform specialization by default? Also, assuming this is with llvm-project/flang.
Mon, Mar 13
LG. Please wait for and OK from @jrtc27.
Fixes one of the issues in https://github.com/llvm/llvm-project/issues/61342.
Sat, Mar 11
Fri, Mar 10
LG.
Thu, Mar 9
@peixin Thanks for working on this. Could you check why the patch application is failing?
Adding @vdonaldson also to check whether this is the right way to do this and also for the interaction with the block construct.
Sorry, I haven't had a chance to look at this in detail. I would need to get up to speed with addrspace in LLVM before proceeding with this. I would recommend someone from your organization review this patch and then @jeanPerier sign this off, if it is OK.
Wed, Mar 8
Tue, Mar 7
LG.
LG. See one minor comment in the tests.
Thanks for the update and the replies. See comments inline.
Mon, Mar 6
Could you add a description in the summary or add a comment in the changed code on what this change does and how it fixes the issue?
I have some more comments.
Fri, Mar 3
Thanks for making the change.
I am still going through the patch, I have a few comments.
Thu, Mar 2
LGTM.
Change name of operation in assert to fix CI failure.
The other option is for Modules to implement an interface and then the Translation can detect this and forward it to the OpenMP Dialect translation in OpenMPToLLVMIRTranslation.cpp.
Wed, Mar 1
Thanks for the changes and the replies.
Tue, Feb 28
LGTM. Please wait for @awarzynski.
Thanks @luporl for having a look. There are a few fixes that are going in the privatisation area. I think the issue you are pointing out with your example will also be fixed by that. This fix is not causing the issue that you are seeing.
Mon, Feb 27
It will also be helpful if you can add TODOs for the types that are not handled.
Could you update the discourse thread (https://discourse.llvm.org/t/rfc-omp-module-and-omp-function-vs-dialect-attributes-to-encode-openmp-properties/67998) with the chosen approach and reasons before proceeding?
Could you update the discourse thread (https://discourse.llvm.org/t/rfc-omp-module-and-omp-function-vs-dialect-attributes-to-encode-openmp-properties/67998) with the chosen approach and reasons before proceeding?
Thanks. LGTM.
This will need a discussion with the FIR team.
ping @mnadeem. Do you need any inputs or helpf to complete this patch?
Thanks, that looks good. The runtime is in charge of mapping and copying the data. I guess it will transparently map the address from the host pointer to the device address space since it stores the mapping.
Note to self: Please add the relevant tests in flang/test/Fir/convert-to-llvm-openmp-and-fir.fir and mlir/test/Conversion/OpenMPToLLVM/convert-to-llvmir.mlir before submitting.