Please use GitHub pull requests for new patches. Avoid migrating existing patches. Phabricator shutdown timeline
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Wed, Nov 29
Tue, Nov 28
Nov 3 2023
Aug 28 2023
Hi Michael,
thank you very much for your work.
Aug 8 2023
Patch rebased.
Applied review remarks - scope of the patch is reduced. It contains only the changes which are required to generate MLIR code for simd aligned clause.
Jul 28 2023
Hi,
thank you for your contribution.
Could you fix assertion failure which was reported by Clang CI ( https://buildkite.com/llvm-project/premerge-checks/builds/166519#01898852-f9c9-4dd2-9933-b32be792c976 ) ?
Assertion failed: OpenMPRuntime != nullptr, file C:\ws\w9\llvm-project\premerge-checks\clang\lib\CodeGen\CodeGenModule.h, line 635
Jul 27 2023
Jul 13 2023
LGTM
Jul 11 2023
Jul 6 2023
Patch not needed. Feature already implemented by https://reviews.llvm.org/D153910
Patch rebased. Use OmpObjectList instead of NameList. Added test cases for C_PTR and Fortran pointers.
Jun 29 2023
Patch not needed. Preprocessor change: https://reviews.llvm.org/D153910 enables passing information about original source file.
LGTM
Jun 28 2023
LGTM.
Thank you for your patch.
I tested it, and it solves all issues connected with -save-temps flag, which were mentioned on LLVM discourse.
Could you fix one check statement in flang/test/Parser/line-directive.f90 which fails on Windows?
Jun 20 2023
Hi @raghavendhra
could you also address this issue: https://github.com/llvm/llvm-project/issues/61161 ?
Jun 19 2023
Patch rebased.
Jun 5 2023
Jun 1 2023
Scope of changes:
- Create one function common for bbc and Flang frontend to set _OPENMP macro
- Use setOpenMPmacro function inside Flang frontend and bbc source code.
May 25 2023
In D151445#4372892, @clementval wrote:You should be able to get this information from the source location in MLIR.
May 22 2023
May 19 2023
OpenMP standard mentions that if implementation of OpenMP supports preprocessor then macro _OPENMP is defined to have value yyyymm, where yyyy denotes the year and mm denotes the month of OpenMP version release. (OpenMP standard 5.2 section 3.3).
Currently Flang has hard coded value of OpenMP 4.5 (see line: https://github.com/llvm/llvm-project/blob/main/flang/lib/Frontend/CompilerInvocation.cpp#L994 )
Shall I add information about other versions?
May 17 2023
In D150354#4348785, @kiranchandramohan wrote:In D150354#4342146, @domada wrote:In D150354#4337148, @awarzynski wrote:All in all LGTM, but I'm not sure whether Flang should be defaulting to OpenMP 5.0. AFAIK, that's not supported yet.
If you wish I can set to OpenMP 4.5. But then we need to have two separate flags in clang/include/clang/Driver/Options.td (one for clang and the second one for flang).
We will not be able to match the OpenMP support in clang (stand support level) soon. Although we have made lot of progress, we are effectively around 1.1. To stay true to the meaning of this metadata, we will have to have separate flags. But, I guess, fclang-openmp-version might not be acceptable to Clang folks who are used to using -fopenmp-version. Can't this be achieved by the same flag? On a cursory look, i don't see anything that prevents using the same flag but with different defaults in the code that is handling the flag.
Change the default version of OpenMP version flag to 1.1 for flang. Modify the flag description text. No changes for Clang code.
May 15 2023
In D150351#4342442, @kiranchandramohan wrote:LG.
Where will the omp.version be set in Flang? Assuming it is in a separate patch.
In D150354#4337148, @awarzynski wrote:All in all LGTM, but I'm not sure whether Flang should be defaulting to OpenMP 5.0. AFAIK, that's not supported yet.
Patch rebased because I applied remarks for parent revision.
In D150351#4337358, @kiranchandramohan wrote:Could you clarify in the commit message that there are two attributes here: One representing the device version (in Flags Attr) and a standalone one called omp.version?
Applied remarks
May 11 2023
Patch rebased + clang format
In D150351#4334629, @agozillon wrote:In D150351#4334624, @kiranchandramohan wrote:In D150351#4334608, @domada wrote:In D150351#4334598, @kiranchandramohan wrote:Will the translation to LLVM be through amendOperation?
That's my plan. If you wish I can wait till the output of @skatrak proposal: https://reviews.llvm.org/D150275
No need to wait. I believe that proposal was only to demonstrate that there is a way for out of tree users to use the Offload Attributes in the Dialect.
Also, if it uses amendOperation then you can consider removing the getVersion since we will not be using it.Another question I have is whether the flags attribute will always be present with -fopenmp or only with some device/target specific options.
Currently the flags were only present on device (and the original intent was it only being these flags, but it makes sense for it to extend broader to cover these flags as well), but that was because the flags that were in the attribute originally are only ever present on the device/target. However, all you would need to do to change this is move the is_device check that applies them in the frontend (initial attribute creation) to the back end (MLIR attribute -> LLVM IR) and then use the is_device flag in amendOperation to filter and generate the flags you wish. This would mean the attribute is present for host and device whenever -fopenmp is specified however, although I don't necessarily see a problem with that!
Resolve dependency between parent and child revision.
Patch rebased
In D150351#4334598, @kiranchandramohan wrote:Will the translation to LLVM be through amendOperation?
Fixed default version of OpenMP
May 9 2023
In D149450#4326431, @ftynse wrote:+@ftynse and @mehdi_amini
I believe Alex or Mehdi said before that the passthrough support was just a temporary solution and we must not rely on it in more places.Indeed. "Passthrough" must not be used unless for quick prototyping to check which attributes are needed before modeling them as properly defined first-class attributes in MLIR. There is no verification, it has strings everywhere. I'll update the documentation to better reflect this.
May 4 2023
Apr 28 2023
Apr 24 2023
Apr 20 2023
Patch rebased
Patch rebased
Apr 17 2023
Apr 13 2023
Fortan parser needs to be modified before we will submit lowering simd aligned clause to MLIR.
Mar 31 2023
Updated mlir definition of target attributes. Use MLIR class StringRefParameter instead std::string
Mar 30 2023
Scope of changes:
- Applied @kiranchandramohan suggestion ( https://reviews.llvm.org/D146721 ) for target interface.
- Patch rebased.
- Limited scope of patch. Lowering from MLIR to LLVM IR will be present in different patch
Mar 29 2023
Mar 28 2023
In D145579#4226542, @tschuett wrote:I wanted to ask whether you want to put an AMDGPU.cpp and AMD.cpp file in the flang/lib/Frontend directory.
Patch rebased and added new test for checking incorrect wavefront sizes AMDGPU target features.
In D145579#4224157, @tschuett wrote:Do you want to move the AMDGPU changes into AMDGPU.cpp next to AMD.cpp? From the conversation, there seems to be more target specific behaviours.
Mar 27 2023
Patch rebased
Rebase & applied review remarks
Mar 23 2023
Hi Kiran,
thanks for the patch.
It looks good to me and I will update my review: https://reviews.llvm.org/D146612 . I will use interface instead of module attributes.
Mar 22 2023
Added OpenMP target attributes from parent review D145579 .
Applied remarks.
Moved OpenMP changes to https://reviews.llvm.org/D146612 .
D146612 presents the lowering from MLIR attributes to LLVM IR.
Patch rebased
Mar 16 2023
Mar 10 2023
Mar 9 2023
Fixed formatting