- User Since
- Jul 12 2021, 6:52 PM (64 w, 11 h)
Sun, Oct 2
Sat, Oct 1
Thu, Sep 29
Please fix the clang-format issue.
The following test case fails.
program main implicit none integer, parameter :: n1 = 10 integer, parameter :: n2 = 100 integer, parameter :: n = 30 integer :: idx(n2) integer :: i integer(1) :: xi1(n1), yi1(n1), zi1(n1), oi1(n1), pi1(n1), qi1(n1), expecti1(n1) integer(8) :: xi8(n1), yi8(n1), zi8(n1), oi8(n1), pi8(n1), qi8(n1), expecti8(n1) logical :: rst(n) = .false.
Wed, Sep 28
Fix clang-format issue.
Add <cstdint> to fix CI fail.
I think, in general, LLVM recommends for performance reasons to put allocas in the entry block. See https://llvm.org/docs/Frontend/PerformanceTips.html#use-of-allocas.
Yes, there will be some over-allocation. But also note that if we did not hoist and there was a loop outside the single construct then this will lead to run-away allocations without a stacksave and stackrestore.
The case of a loop is a little more complicated, since we need to place the allocas for loops in the header of the loop which is not available in the loop form, it is only available when we break the loop into control-flow form. So it is not possible to do it in the high-level MLIR.
These issues will probably be resolved when we move privatisation clauses to the OpenMP dialect and handle it in the OpenMPIRBuilder.The alloca ops can be hoisted outside the single region, but the store op for firstprivate clause should be in single region.
Yes, this is important. Otherwise, any updates to the value will not be available. I don't remember whether we fixed the issue or whether it is still present. It was captured in https://github.com/flang-compiler/f18-llvm-project/issues/1171#issuecomment-1119997442
Implemented in runtime.
Tue, Sep 27
Why wouldn't getAllocaBlock work by itself? From our understanding of Clang it is not required for the private allocas to be inside the runtime calls, so getAllocaBlock will hoist it to the nearest region that will be outlined. Isn't that sufficient?
Mon, Sep 26
Thanks @kiranchandramohan for pointing out the problem.
Sat, Sep 24
Rebase and add the test case as suggested.
Fri, Sep 23
Thu, Sep 22
Wed, Sep 21
Thanks for addressing the comments and explanations. LGTM.
Can you consider more cases such as follows:
subroutine sub complex :: a, b, c c = conj(a) * b end
and -a * b and -conj(a) * b.
LGTM. Tested on one little-endian machine with our internal tests (I attached them in the issue https://github.com/llvm/llvm-project/issues/55961) for the priority of -fconvert= option and CONVERT argument in open statement and all passed. I didn't see the the GFORTRAN_CONVERT_UNIT used in HPC workloads and don't have tests for it. For now, I would avoid full combination tests for it.
Very good design. This seems to be one promising method to handle some bugs in forall, pattern match for inline intrinsics and OpenMP reduction (not totally sure if it will work), and expected to have more information of variables and expression for performance optimization in FIR.
Tue, Sep 20
The build still fails.
Mon, Sep 19
Reimplement this as @clementval suggested.
Sun, Sep 18
Fri, Sep 16
Add "-triple aarch64-unknown-linux-gnu" to fix the CI fail. Do not know why the test case is still checked even with ! REQUIRES: aarch64-registered-target.
Rebase and address the data race problem for single construct.
No test cases?
LGTM since this patch is doing the lowering part as the title and summary mentioned.
Thu, Sep 15
Tue, Sep 13
@domada I will update this patch later this week.
Sat, Sep 10
Fri, Sep 9
Tue, Sep 6
Mon, Sep 5
Thanks @jeanPerier for the info. Move it into the Optimizer/Builder/FIRBuilder as suggested.
Sep 3 2022
Sep 2 2022
Mostly LGTM. Have several more comments.
Reimplement this according to @jeanPerier 's suggestions.
Aug 31 2022
Aug 30 2022
Aug 29 2022
Aug 27 2022
Address the comments.
Aug 26 2022
$ cat fconvert_option_main_2.f90 ! ! Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. ! See https://llvm.org/LICENSE.txt for license information. ! SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception ! ! checking for I/O: testing read with -fconvert=big-endian. ! The convert argument of open function has prior claim over fconvert option. ! Only main program intentionally compiled with -fconvert=big-endian.
LGTM. The CI failed. Please make sure the CI passed before landing.
Aug 25 2022
- Support the callee side.
Aug 24 2022
This needs rebase. I failed to apply this patch due to conflict.
Aug 23 2022
Aug 22 2022
Fix the typo and reuse the function in ConvertVariable.cpp.
LGTM. Checked ifort 2021 iso_c_binding.f90 and it has BIND(C) for both C_PTR and C_FUNPTR.
Aug 21 2022
Aug 20 2022
Evaluated the end-to-end execution result using the following example.
$ cat main.f90 program main use iso_c_binding real, pointer :: cptr, cptr2(:,:) real, pointer :: fptr, fptr2(:,:) integer :: x = 3, y = 4 type(c_ptr) :: foo