The lower bound information for the array members of a derived type
can't be obtained from the `DeclareOp`. It has to be extracted from the
`TypeInfoOp`. That was left as FIXME in the code. This PR adds the
missing functionality to fix the issue.
I tried the following approaches before settling on the current one that
is to generate `DITypeAttr` for array members right where the components
are being processed.
1. Generate a temp XDeclareOp with the shift information obtained from
the `TypeInfoOp`. This caused a few issues mostly related to
`unrealized_conversion_cast`.
2. Change the shift operands in the `declOp` that was passed in the
function before calling `convertType`. The code can be seen in the
abcf031a8e5a02f0081e7f293858302e7bf47bec. It essentially looked like the
following. It works correctly but I was not sure if temporarily changing
the `declOp` is the safe thing to do.
```
mlir::OperandRange originalShift = declOp.getShift();
mlir::MutableOperandRange mutableOpRange = declOp.getShiftMutable();
mutableOpRange.assign(shiftOpers);
elemTy = convertType(fieldTy, fileAttr, scope, declOp);
mutableOpRange.assign(originalShift);
```
Fixes#113178.
Flang generates many globals to handle derived types. There was a check
in debug info to filter them based on the information that their names
start with a period. This changed since PR#104859 where 'X' is being
used instead of '.'.
This PR fixes this issue by also adding 'X' in that list. As user
variables gets lower cased by the NameUniquer, there is no risk that
those will be filtered out. I added a test for that to be sure.
This PR adds an OpenMP dialect related pass for FIR/HLFIR which creates
`MapInfoOp` instances for certain privatized symbols. For example, if an
allocatable variable is used in a private clause attached to a
`omp.target` op, then the allocatable variable's descriptor will be
needed on the device (e.g. GPU). This descriptor needs to be separately
mapped onto the device. This pass creates the necessary `omp.map.info`
ops for this.
Currently, we allow only one DIGlobalVariableExpressionAttr per global.
It is especially evident in import where we pick the first from the list
and ignore the rest. In contrast, LLVM allows multiple
DIGlobalVariableExpression to be attached to the global. They are needed
for correct working of things like DICommonBlock. This PR removes this
restriction in mlir. Changes are mostly mechanical. One thing on which I
went a bit back and forth was the representation inside GlobalOp. I
would be happy to change if there are better ways to do this.
---------
Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com>
For example, in
PROGRAM test_program
...
END PROGRAM
This allows a user to break on the main function with `break
test_program`. This matches what classic flang and gfortran do.
The debug information generated by flang did not handle the cases where
dimension or lower bounds of the arrays were variable. This PR fixes
this issue. It will help distinguish assumed size arrays from cases
where array size are variable. It also handles the variable lower bounds
for assumed shape arrays.
Fixes#98879.
This patch updates printing and parsing of operations including clauses
that define entry block arguments to the operation's region. This
impacts `in_reduction`, `map`, `private`, `reduction` and
`task_reduction`.
The proposed representation to be used by all such clauses is the
following:
```
<clause_name>([byref] [@<sym>] %value -> %block_arg [, ...] : <type>[, ...]) {
...
}
```
The `byref` tag is only allowed for reduction-like clauses and the
`@<sym>` is required and only allowed for the `private` and
reduction-like clauses. The `map` clause does not accept any of these
two.
This change fixes some currently broken op representations, like
`omp.teams` or `omp.sections` reduction:
```
omp.teams reduction([byref] @<sym> -> %value : <type>) {
^bb0(%block_arg : <type>):
...
}
```
Additionally, it addresses some redundancy in the representation of the
previously mentioned cases, as well as e.g. `map` in `omp.target`. The
problem is that the block argument name after the arrow is not checked
in any way, which makes some misleading representations legal:
```mlir
omp.target map_entries(%x -> %arg1, %y -> %arg0, %z -> %doesnt_exist : !llvm.ptr, !llvm.ptr, !llvm.ptr) {
^bb0(%arg0 : !llvm.ptr, %arg1 : !llvm.ptr, %arg2 : !llvm.ptr):
...
}
```
In that case, `%x` maps to `%arg0`, contrary to what the representation
states, and `%z` maps to `%arg2`. `%doesnt_exist` is not resolved, so it
would likely cause issues if used anywhere inside of the operation's
region.
The solution implemented in this patch makes it so that values
introduced after the arrow on the representation of these clauses
implicitly define the corresponding entry block arguments, removing the
potential for these problematic representations. This is what is already
implemented for the `private` and `reduction` clauses of `omp.parallel`.
There are a couple of consequences of this change:
- Entry block argument-defining clauses must come at the end of the
operation's representation and in alphabetical order. This is because
they are printed/parsed as part of the region and a standardized
ordering is needed to reliably match op arguments with their
corresponding entry block arguments via the `BlockArgOpenMPOpInterface`.
- We can no longer define per-clause assembly formats to be reused by
all operations that take these clauses, since they must be passed to a
custom printer including the region and arguments of all other entry
block argument-defining clauses. Code duplication and potential for
introducing issues is minimized by providing the generic
`{print,parse}BlockArgRegion` helpers and associated structures.
MLIR and Flang lowering unit tests are updated due to changes in the
order and formatting of impacted operations.
As mentioned in #108633, we don't respect the lower bound of the assumed
shape arrays if those were specified. It happens in both cases:
1. When caller has non-default lower bound and callee has default
2. When callee has non-default lower bound and caller has default
This PR tries to fix this issue by improving our generation of lower
bound attribute on DICompositeTypeAttr. If we see a lower bound in the
declaration, we respect that. Note that same function is also used for
allocatable/pointer variables. We make sure that we get the lower bound
from descriptor in those cases. Please note that DWARF assumes a lower
bound of 1 so in many cases we don't need to generate the lower bound.
Fixes#108633.
Our support for derived types uses `getTypeSizeAndAlignment` to
calculate the offset of the members. The `fir.box` was not supported in
that function. It meant that any member which required descriptor was
not supported in the derived type.
We convert the type into an llvm type and then use the DataLayout to
calculate the size/offset of a member. There is no dependency on
`getTypeSizeAndAlignment` to get the size of the types.
There are 2 other changes in this PR:
1. The `recID` field is used to handle cases where we have a member
references its parent type.
2. A type cache is maintained to avoid duplication. It is also needed
for circular reference case.
Fixes#108001.
As described in #107998, we were not handling the case well when length
of the character is not part of the type. This PR handles one of the
case when the length can be calculated by looking at the result of
corresponding `fir.unboxchar`.
The DIStringTypeAttr have a `stringLength` field that can be a variable.
We create an artificial variable that will hold the length and used as
value of `stringLength` field. The variable is then attached with
a `DbgValueOp`.
Fixes#107998.
We pass a list of types when creating a subroutine type. The first one
is supposed to be return type and the rest are the argument types. A
subroutine does not have a return type so an argument type could be
confused as a return type. To fix this, if there is no return type, we
generate a null type as a place holder.
Fixes#108564.
The new LLVM stack save/restore intrinsic operations are more convenient
than function calls because they do not add function declarations to the
module and therefore do not block the parallelisation of passes.
Furthermore they could be much more easily marked with memory effects
than function calls if that ever proved useful.
This builds on top of #107879.
Resolves#108016
As described in #98883, we have to qualify a module variable name in
debugger to get its value. This PR tries to remove this limitation.
LLVM provides `DIImportedEntity` to handle such cases but the PR is made
more complicated due to the following 2 issues.
1. The MLIR attributes are readonly and we have a circular dependency
here. This has to be handled using the recursive interface provided by
the MLIR. This requires us to first create a place holder
`DISubprogramAttr` which is used in creating `DIImportedEntityAttr`.
Later another `DISubprogramAttr` is created which replaces the place
holder.
2. The flang IR does not provide any information about the 'used' module
so this has to be extracted by doing a pass over the
`DeclareOp` in the function. This presents certain limitation as 'only'
and module variable renaming may not be handled properly.
Due to the change in `DISubprogramAttr`, some tests also needed to be
adjusted.
Fixes#98883.
This PR adds initial debug support for derived type. It handles
`RecordType` and generates appropriate `DICompositeTypeAttr`. The
`TypeInfoOp` is used to get information about the parent and location of
the derived type.
We use `getTypeSizeAndAlignment` to get the size and alignment of the
components of the derived types. This function needed a few changes to
be suitable to be used here:
1. The `getTypeSizeAndAlignment` errored out on unsupported type which
would not work with incremental way we are building debug support. A new
variant of this function has been that returns an std::optional. The original
function has been renamed to `getTypeSizeAndAlignmentOrCrash` as it
will call `TODO()` for unsupported types.
2. The Character type was returning size of just element and not the
whole string which has been fixed.
The testcase checks for offsets of the components which had to be
hardcoded in the test. So the testcase is currently enabled on x86_64.
With this PR in place, this is how the debugging of derived types look
like:
```
type :: t_date
integer :: year, month, day
end type
type :: t_address
integer :: house_number
end type
type, extends(t_address) :: t_person
character(len=20) name
end type
type, extends(t_person) :: t_employee
type(t_date) :: hired_date
real :: monthly_salary
end type
type(t_employee) :: employee
(gdb) p employee
$1 = ( t_person = ( t_address = ( house_number = 1 ), name = 'John', ' ' <repeats 16 times> ), hired_date = ( year = 2020, month = 1, day = 20 ), monthly_salary = 3.1400001 )
```
As mentioned in #98877, we currently always use 1 as lower bound for
fixed size arrays. This PR removes this restriction. It passes along
`DeclareOp` to type conversion functions and uses the shift information
(if present) to get the lower bound value. This was suggested by
@jeanPerier in
https://github.com/llvm/llvm-project/pull/96746#issuecomment-2195164553
This PR also adds a small cleanup that type conversion functions don't
take Location now. It was initially added so that location of derived
types can be passed. But that information can be extracted from typeInfo
objects and we don't need to pass it along.
This PR will handle the problem for local and global variable. We may
need a bit more work for derived type once the support for derived types
lands.
Fixes#98877.
We missed collecting the analysis results for regions terminated with
`omp.yield`. This result in missing some opportunities for malloc
optimizations inside omp regions.
The functions internal to subroutine should have the scope set to the
parent function. This allows a user to evaluate local variables of
parent function when control is stopped in the child.
Fixes#96314
The `ExternalNameConversion` will add an _ at the end of the external
functions. We extract the real function name to use in the debug info.
The convention is to use the real name of function in the `name` field
and mangled name with extra _ at the end in the `linkageName` field.
Fixes#92391.
Extends the stack-arrays pass to support `fir.declare` ops. Before that,
we did not recognize malloc-free pairs for which `fir.declare` is used
to declare the allocated entity. This is because the `free` op was
invoked on the result of the `fir.declare` op and did not directly use
the allocated memory SSA value.
This also extends the pass to collect the analysis results within OpenMP
regions.
This PR fixes 2 similar issues.
1. As reported in #97476, flang generated executable has inconsistent
behavior regarding values of the local array variables.
2. Variable with save attribute would not show up in debugger.
The reason behind is same for both cases. If a local variable has
storage which extends beyond function lifetime, the way to represent it
in the debug info is through a global variable whose scope is limited to
the function. This is what is used for static local variable in C.
Previously local array worked in cases they were on stack. But will not
show up if they had a global storage.
To fix this, if we can get a corresponding `GlobalOp` for a variable
while processing `DeclareOp`, we treat it the variable as global with
scope set appropriately. A new FIR test is added. A previous Integration
test has been adjusted as to not expect local variables for local
arrays.
With this fix in place, all the issues described in #97476 go away. It
also fixes a lot of fails in GDB's fortran testsuite.
Fixes#97476.
The code that handled allocatable array had swapped `count` with
`upperBound`. This did not get caught earlier as all the example were
using 1 as `lowerBound`.
Fixes#98166.
With the fix in place, the GDB now correctly handles the case pointed in
the bug ticket.
(gdb) p min::alloc2d
$2 = ((0, 0, 0) (0, 0, 0) (0, 0, 0) (0, 0, 0) (0, 0, 0))
(gdb) ptype min::alloc2d
type = integer, allocatable (-1:1,-2:2)
Here we don't know the size of last dimension and use a null subrange
for that. User will have to provide the dimension when evaluating
variable of this type. The debugging looks like as follows:
subroutine fn(a1, a2)
integer a1(5, *), a2(*)
...
end
(gdb) p a1(1,2)
$2 = 2
(gdb) p a2(3)
$3 = 3
(gdb) ptype a1
type = integer (5,*)
(gdb) ptype a2
type = integer (*)
This PR aims to factor in the allocation address space provided by an
architectures data layout when generating the intrinsic instructions,
this allows them to be lowered later with the address spaces in tow.
This aligns the intrinsic creation with the LLVM IRBuilder's
https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/IR/IRBuilder.h#L1053
This is also necessary for the below example to compile for OpenMP AMD
GPU and not ICE the compiler in ISEL as AMD's stackrestore and stacksave
are expected to have the appropriate allocation address space for AMD
GPU.
program main
integer(4), allocatable :: test
allocate(test)
!$omp target map(tofrom:test)
do i = 1, 10
test = test + 50
end do
!$omp end target
deallocate(test)
end program
The PR also fixes the issue I opened a while ago which hits the same
error when compiling for AMDGPU:
https://github.com/llvm/llvm-project/issues/82368
Although, you have to have the appropriate GPU LIBC and Fortran offload
runtime (both compiled for AMDGPU) added to the linker for the command
or it will reach another ISEL error and ICE weirdly. But with the
pre-requisites it works fine with this PR.
Constants actual arguments in function/subroutine calls are currently
lowered as allocas + store. This can sometimes inhibit LTO and the
constant will not be propagated to the called function. Particularly in
cases where the function/subroutine call happens inside a condition.
This patch changes the lowering of these constant actual arguments to a
global constant + fir.address_of_op. This lowering makes it easier for
LTO to propagate the constant.
The optimization must be enabled explicitly to run. Use -mmlir
--enable-constant-argument-globalisation to enable.
---------
Co-authored-by: Dmitriy Smirnov <dmitriy.smirnov@arm.com>
The handling of `PointerType` is similar to `HeapType`. The only
difference is that allocated flag is generated for `HeapType` and
associated flag for `PointerType`. The tests for pointer to allocatable
strings are disabled for now. I will enable them once #95906 is merged.
The debugging in GDB looks like this:
integer, pointer :: par2(:)
integer, target, allocatable :: ar2(:)
integer, target :: sc
integer, pointer :: psc
allocate(ar2(4))
par2 => ar2
psc => sc
19 par2 => ar2
(gdb) p par2
$3 = <not associated>
(gdb) n
20 do i=1,5
(gdb) p par2
$4 = (0, 0, 0, 0)
(gdb) ptype par2
type = integer (4)
(gdb) p sc
$5 = 3
(gdb) p psc
$6 = (PTR TO -> ( integer )) 0x7fffffffda24
(gdb) p *psc
$7 = 3
The allocatable strings also use DIStringType but provide dwarf
expressions to find the location and length of the string. With this
change in place, the debugging of the allocatable strings looks like
this:
character(len=:), allocatable :: first
character(len=:), allocatable :: second
character(len=:), allocatable :: third
first = 'Mount'
second = 'Everest'
third = first // " " // second
print *, third
(gdb) p third
$1 = ""
(gdb) n
18 print *, third
(gdb) p third
$2 = 'Mount Everest'
(gdb) ptype third
type = character (13)
@kiranchandramohan mentioned
[here](https://github.com/llvm/llvm-project/pull/91582#discussion_r1606046605)
that LLVM IR tests should go in the Integration folder. He also
mentioned
[here](https://github.com/llvm/llvm-project/pull/91582#discussion_r1606684034)
that tests for `add-debug-info` pass should test that pass only. There
were some tests which were added before his comments so I have cleaned
them in this PR. The following changes were made.
1. Move LLVM IR tests to `Integration` folder.
2. Change tests from f90 to fir and only test changes done by
`add-debug-info` pass.
This PR adds debug support for allocatable. The allocatable arrays use
the existing functionality to read the array information from
descriptor. The allocatable for the scalar shows up as pointer to the
scalar.
While testing this, I notices that values of allocated and associated
flags were swapped. This is also fixed in this PR.
Here is how the debugging of the allocatable looks like with this patch
in place.
integer, allocatable :: ar1(:, :)
real, allocatable :: sc
allocate(sc)
allocate(ar1(3, 4))
(gdb) ptype ar1
type = integer, allocatable (3,4)
(gdb) p ar1
$1 = ((5, 6, 7) (9, 10, 11) (13, 14, 15) (17, 18, 19)) (gdb) p sc
$2 = (PTR TO -> ( real )) 0x205300
(gdb) p *sc
$3 = 3.1400001
This PR adds debug support for fixed size character type. The character
type gets translated to DIStringType.
As I have noticed in comments, currently DIStringType does not have a
way to represent the underlying character type of the string. This
restricts our ability to represent wide string. As an example, this is
how the debugger shows 2 different type of string. Note that non-ascii
characters work ok with default kind string.
character(kind=4, len=5) :: str1
character(len=16) :: str2
str1 = 'hello'
str2 = 'π = 3.14'
(gdb) p str1
$1 = 'h\000\000\000e\000\000\000l\000\000\000l\000\000\000o\000\000\000'
(gdb) p str2
$2 = 'π = 3.14 '
Some passes in the flang pipeline are creating `fir.alloca` operation
like `hlfir.concat`. When these allocas are located in a loop, the stack
can quickly be used too much leading to segfaults.
This behavior can be seen in
https://github.com/jacobwilliams/json-fortran/blob/master/src/tests/jf_test_36.F90
This patch insert a call to LLVM stacksave/stackrestore in the body of
the loop to reclaim the alloca in its scope.
This PR is an alternative implementation to #95173
Reapplies commit c5aeca73 (and its followup commit 21396be8), which were
reverted due to missing functionality in MLIR and Flang regarding printing
debug records. This has now been added in commit 08aa511, along with support
for printing debug records in flang.
This reverts commit 2dc2290860.
Fixed the link error that previously occurred on buildbots by adding
IRPrinter to the linked components of the Flang frontend.
This reverts commit 1d4523505e.
The Flang frontend currently prints LLVM IR modules using
llvm::Module::print(); this works for default cases, but skips some of
the logic that IR printer passes use, specifically the use of the
--write-experimental-debuginfo flag to control debug info format. This
patch replaces the use of print() with the PrintModulePass, bringing the
printing behaviour to parity with clang's frontend.
"[Flang] Update test to not check for tail calls on debug intrinsics" &
"Reapply#3 "[RemoveDIs] Load into new debug info format by default in LLVM (#89799)"
Recent updates to flang have added debug info generation via MLIR, a path
which currently does not support debug records. The patch that enables
debug records by default (and a small followup patch) are thus being
reverted until the MLIR path has been fixed.
This reverts commits:
21396be865c5aeca732d
This PR generates dwarf to extract the information about the arrays from
descriptor. The DWARF needs the offset of the fields like `lower_bound`
and `extent`. The getComponentOffset has been added to calculate
them which pushes the issue of host and target data size into
getDescFieldTypeModel.
As we use data layout now, some tests needed to be adjusted to have a
dummy data layout to avoid failure.
With this change in place, GDB is able show the assumed shape arrays
correctly.
subroutine ff(n, m, arr)
integer n, m
integer :: arr(:, :)
print *, arr
do i = 1, n
do j = 1, m
arr(j, i) = (i * 5) + j + 10
end do
end do
print *, arr
end subroutine ff
Breakpoint 1, ff (n=4, m=3, arr=...) at test1.f90:13
13 print *, arr
(gdb) p arr
$1 = ((6, 7, 8, 9) (11, 12, 13, 14) (16, 17, 18, 19))
(gdb) ptype arr
type = integer (4,3)
(gdb) c
Continuing.
6 7 8 9 11 12 13 14 16 17 18 19
The recently landed commit c5aeca73 causes debug records to be used by
default; while this mostly has no direct effect on output, one side
effect is that intrinsics are deleted and recreated in memory, which
can change certain properties. This broke a test that expected `tail`
to be set on some debug intrinsics; as this property has no effect on
debug intrinsics, this patch removes the expectation.
Committed without review due to being a trivial test update; if this
needs discussion, see review:
https://github.com/llvm/llvm-project/pull/89799
With MLIR inlining (e.g. `flang-new -mmlir -inline-all=true`)
the current TBAA tags attachment is suboptimal, because
we may lose information about the callee's dummy arguments
(by bypassing fir.declare in AliasAnalysis::getSource).
This is a conservative first step to improve the situation.
This patch makes AddAliasTagsPass to account for fir.dummy_scope
hierarchy after MLIR inlining and use it to place the TBAA tags
into TBAA trees corresponding to different function scopes.
The pass uses special mode of AliasAnalysis to find the instantiation
point of a Fortran variable (a [hl]fir.decalre) when searching
for the source of a memory reference. In this mode, AliasAnalysis
will always stop at fir.declare operations that have dummy_scope
operands - there should not be a reason to past throught it
for the purpose of TBAA tags attachment.
