[flang][docs] Fix broken flang website (#80363)
These are several fixes for the flang site. The look has been changed to match clang since flang, like clang, is a frontend. Some broken links were removed. Most fixes are to secton titles so the table of contents is generated correctly. A minor typo has been fixed.
This commit is contained in:
Tarun Prabhu
GitHub
parent
74fb205876
commit
7ca4012e11
@ -74,12 +74,12 @@ Because of block arguments, a memory reference may have multiple sources. If a b
|
||||
### Pointer type
|
||||
A type `fir.box<fir.ptr<T>>` or `fir.ptr<T>`
|
||||
|
||||
# Aliasing rules
|
||||
## Aliasing rules
|
||||
The goal is to match [Fortran’s rule for aliasing](Aliasing.md). However FIR is all we have at this stage so the hope is that we can define an algorithm using the information from FIR to properly model Fortran’s aliasing rules. Wherever there is a gap, we may have to refine the algorithm, add information in FIR or both. Though, with the introduction of the fir.declare operation, most of the source level information relevant to aliasing will be populated in FIR.
|
||||
|
||||
The first attempt to determine aliasing will be at the coarsest level: the source level. The answer to the query will be ‘yes’, ‘no’, ‘maybe’. If the answer is ‘yes’ or ‘no’, the query is complete. If the answer is ‘maybe’ then further analysis is required until a definite answer is reached. If no finer analysis is available then 'maybe' is returned.
|
||||
|
||||
## Coarse rules
|
||||
### Coarse rules
|
||||
Distinct sources are assumed to not alias except in the following cases:
|
||||
1. A pointer type source may alias with any other pointer type source.
|
||||
1. A source with the fir.target attribute may alias with any other pointer type source.
|
||||
|
||||
@ -90,7 +90,7 @@ reference, and its semantics guarantee immutability.
|
||||
// a fir.store here into array %a does not change %v
|
||||
```
|
||||
|
||||
# array_merge_store
|
||||
## array_merge_store
|
||||
|
||||
The `array_merge_store` operation stores a merged array value to memory.
|
||||
|
||||
|
||||
@ -383,7 +383,7 @@ At this point you should be able to trigger that frontend action that you have
|
||||
just added using your new frontend option.
|
||||
|
||||
|
||||
# CMake Support
|
||||
## CMake Support
|
||||
As of [#7246](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7246)
|
||||
(and soon to be released CMake 3.24.0), `cmake` can detect `flang-new` as a
|
||||
supported Fortran compiler. You can configure your CMake projects to use
|
||||
@ -397,7 +397,7 @@ You should see the following in the output:
|
||||
```
|
||||
where `<version>` corresponds to the LLVM Flang version.
|
||||
|
||||
# Testing
|
||||
## Testing
|
||||
In LIT, we define two variables that you can use to invoke Flang's drivers:
|
||||
* `%flang` is expanded as `flang-new` (i.e. the compiler driver)
|
||||
* `%flang_fc1` is expanded as `flang-new -fc1` (i.e. the frontend driver)
|
||||
@ -416,7 +416,7 @@ test as only available on Unix-like systems (i.e. systems that contain a Unix
|
||||
shell). In practice this means that the corresponding test is skipped on
|
||||
Windows.
|
||||
|
||||
# Frontend Driver Plugins
|
||||
## Frontend Driver Plugins
|
||||
Plugins are an extension to the frontend driver that make it possible to run
|
||||
extra user defined frontend actions, in the form of a specialization of a
|
||||
`PluginParseTreeAction`. These actions are run during compilation, after
|
||||
@ -429,7 +429,7 @@ plugins. The process for using plugins includes:
|
||||
Flang plugins are limited to `flang-new -fc1` and are currently only available /
|
||||
been tested on Linux.
|
||||
|
||||
## Creating a Plugin
|
||||
### Creating a Plugin
|
||||
There are three parts required for plugins to work:
|
||||
1. [`PluginParseTreeAction` subclass](#a-pluginparsetreeaction-subclass)
|
||||
1. [Implementation of `ExecuteAction`](#implementation-of-executeaction)
|
||||
@ -439,7 +439,7 @@ There is an example plugin located in `flang/example/PrintFlangFunctionNames`
|
||||
that demonstrates these points by using the `ParseTree` API to print out
|
||||
function and subroutine names declared in the input file.
|
||||
|
||||
### A `PluginParseTreeAction` Subclass
|
||||
#### A `PluginParseTreeAction` Subclass
|
||||
This subclass will wrap everything together and represent the `FrontendAction`
|
||||
corresponding to your plugin. It will need to inherit from
|
||||
`PluginParseTreeAction` (defined in `flang/include/flang/FrontendActions.h`), in
|
||||
@ -449,7 +449,7 @@ can be registered, e.g.
|
||||
class PrintFunctionNamesAction : public PluginParseTreeAction
|
||||
```
|
||||
|
||||
### Implementation of `ExecuteAction`
|
||||
#### Implementation of `ExecuteAction`
|
||||
Like in other frontend actions, the driver looks for an `ExecuteAction` function
|
||||
to run, so in order for your plugin to do something, you will need to implement
|
||||
the `ExecuteAction` method in your plugin class. This method will contain the
|
||||
@ -494,7 +494,7 @@ defined in `flang/include/flang/Parser/parse-tree.h`. In the example, there is a
|
||||
the `FunctionStmt` struct and prints it. This function will be run after every
|
||||
`FunctionStmt` node is visited in the parse tree.
|
||||
|
||||
### Plugin Registration
|
||||
#### Plugin Registration
|
||||
A plugin registry is used to store names and descriptions of a collection of
|
||||
plugins. The Flang plugin registry, defined in
|
||||
`flang/include/flang/Frontend/FrontendPluginRegistry.h`, is an alias of
|
||||
@ -509,7 +509,7 @@ static FrontendPluginRegistry::Add<PrintFunctionNamesAction> X(
|
||||
"print-fns", "Print Function names");
|
||||
```
|
||||
|
||||
## Loading and Running a Plugin
|
||||
### Loading and Running a Plugin
|
||||
In order to use plugins, there are 2 command line options made available to the
|
||||
frontend driver, `flang-new -fc1`:
|
||||
* [`-load <dsopath>`](#the--load-dsopath-option) for loading the dynamic shared
|
||||
@ -525,19 +525,19 @@ Both these options are parsed in `flang/lib/Frontend/CompilerInvocation.cpp` and
|
||||
fulfil their actions in
|
||||
`flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp`
|
||||
|
||||
### The `-load <dsopath>` option
|
||||
#### The `-load <dsopath>` option
|
||||
This loads the plugin shared object library, with the path given at `<dsopath>`,
|
||||
using `LoadLibraryPermantly` from LLVM's `llvm::sys::DynamicLibrary`, which
|
||||
itself uses `dlopen`. During this stage, the plugin is registered with the
|
||||
registration line from the plugin, storing the name and description.
|
||||
|
||||
### The `-plugin <name>` option
|
||||
#### The `-plugin <name>` option
|
||||
This sets `frontend::ActionKind programAction` in `FrontendOptions` to
|
||||
`PluginAction`, through which it searches the plugin registry for the plugin
|
||||
name from `<name>`. If found, it returns the instantiated plugin, otherwise it
|
||||
reports an error diagnostic and returns `nullptr`.
|
||||
|
||||
## Enabling In-Tree Plugins
|
||||
### Enabling In-Tree Plugins
|
||||
For in-tree plugins, there is the CMake flag `FLANG_PLUGIN_SUPPORT`, enabled by
|
||||
default, that controls the exporting of executable symbols from `flang-new`,
|
||||
which plugins need access to. Additionally, there is the CMake flag
|
||||
@ -547,7 +547,7 @@ example programs are built. This includes plugins that are in the
|
||||
`flang/examples/CMakeLists.txt`, for example, the `PrintFlangFunctionNames`
|
||||
plugin. It is also possible to develop plugins out-of-tree.
|
||||
|
||||
## Limitations
|
||||
### Limitations
|
||||
Note that the traversal API presented here is under active development and
|
||||
might change in the future. We expect it to evolve as support for new
|
||||
language features are added. This document and the examples will be updated
|
||||
@ -564,7 +564,7 @@ to re-analyze expressions and modify scope or symbols. You can check
|
||||
[Semantics.md](Semantics.md) for more details on how `ParseTree` is edited
|
||||
e.g. during the semantic checks.
|
||||
|
||||
# LLVM Pass Plugins
|
||||
## LLVM Pass Plugins
|
||||
|
||||
Pass plugins are dynamic shared objects that consist of one or more LLVM IR
|
||||
passes. The `-fpass-plugin` option enables these passes to be passed to the
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
# High-Level Fortran IR (HLFIR)
|
||||
|
||||
The approach of FIR and lowering design so far was to start with the minimal set
|
||||
of IR operations that could allow implementing the core aspects of Fortran (like
|
||||
memory allocations, array addressing, runtime descriptors, and structured
|
||||
@ -41,9 +43,9 @@ The core impact on lowering will be:
|
||||
relevant.
|
||||
|
||||
|
||||
# Variable and Expression value concepts in HLFIR
|
||||
## Variable and Expression value concepts in HLFIR
|
||||
|
||||
## Strengthening the variable concept
|
||||
### Strengthening the variable concept
|
||||
|
||||
Fortran variables are currently represented in FIR as mlir::Value with reference
|
||||
or box type coming from special operations or block arguments. They are either
|
||||
@ -128,7 +130,7 @@ from the caller scope name and the function name.). In general, fir.declare
|
||||
will allow to view every memory storage as a variable, and this will be used to
|
||||
describe and use compiler created array temporaries.
|
||||
|
||||
## Adding an expression value concept in HLFIR
|
||||
### Adding an expression value concept in HLFIR
|
||||
|
||||
Currently, Fortran expressions can be represented as SSA values for scalar
|
||||
logical, integer, real, and complex expressions. Scalar character or
|
||||
@ -1353,9 +1355,9 @@ will be inlined, hlfir.forall will be rewritten into normal loops taking into
|
||||
account the alias analysis, and hlfir.assign/hlfir.designate operations will be
|
||||
lowered to fir.array_coor and fir.store operations).
|
||||
|
||||
# Alternatives that were not retained
|
||||
## Alternatives that were not retained
|
||||
|
||||
## Using a non-MLIR based mutable CFG representation
|
||||
### Using a non-MLIR based mutable CFG representation
|
||||
|
||||
An option would have been to extend the PFT to describe expressions in a way
|
||||
that can be annotated and modified with the ability to introduce temporaries.
|
||||
@ -1364,9 +1366,9 @@ infrastructure and data structures while FIR is already using MLIR
|
||||
infrastructure, so enriching FIR seems a smoother approach and will benefit from
|
||||
the MLIR infrastructure experience that was gained.
|
||||
|
||||
## Using symbols for HLFIR variables
|
||||
### Using symbols for HLFIR variables
|
||||
|
||||
### Using attributes as pseudo variable symbols
|
||||
#### Using attributes as pseudo variable symbols
|
||||
|
||||
Instead of restricting the memory types an HLFIR variable can have, it was
|
||||
force the defining operation of HLFIR variable SSA values to always be
|
||||
@ -1390,7 +1392,7 @@ doing code motion, and whose complexity would be increased by the naming
|
||||
constraints.
|
||||
|
||||
|
||||
### Using MLIR symbols for variables
|
||||
#### Using MLIR symbols for variables
|
||||
|
||||
Using MLIR symbols for HLFIR variables has been rejected because MLIR symbols
|
||||
are mainly intended to deal with globals and functions that may refer to each
|
||||
@ -1407,9 +1409,9 @@ Using SSA values also makes the transition and mixture with lower-level FIR
|
||||
operations smoother: a variable SSA usage can simply be replaced by lower-level
|
||||
FIR operations using the same SSA value.
|
||||
|
||||
## Using some existing MLIR dialects for the high-level Fortran.
|
||||
### Using some existing MLIR dialects for the high-level Fortran.
|
||||
|
||||
### Why not using Linalg dialect?
|
||||
#### Why not using Linalg dialect?
|
||||
|
||||
The linalg dialects offers a powerful way to represent array operations: the
|
||||
linalg.generic operation takes a set of input and output arrays, a related set
|
||||
@ -1438,7 +1440,7 @@ semi-affine cases).
|
||||
So using linalg is for now left as an optimization pass opportunity in some
|
||||
cases that could be experimented.
|
||||
|
||||
### Why not using Shape dialect?
|
||||
#### Why not using Shape dialect?
|
||||
|
||||
MLIR shape dialect gives a set of operations to manipulate shapes. The
|
||||
shape.meet operation is exactly similar with hlfir.shape_meet, except that it
|
||||
@ -1451,7 +1453,7 @@ shape.meet The shape dialect is a lot more complex because it is intended to
|
||||
deal with computations involving dynamically ranked entity, which is not the
|
||||
case in Fortran (assumed rank usage in Fortran is greatly limited).
|
||||
|
||||
## Using embox/rebox and box as an alternative to fir.declare/hlfir.designate and hlfir.expr/ variable concept
|
||||
### Using embox/rebox and box as an alternative to fir.declare/hlfir.designate and hlfir.expr/ variable concept
|
||||
|
||||
All Fortran entities (*) can be described at runtime by a fir.box, except for
|
||||
some attributes that are not part of the runtime descriptors (like TARGET,
|
||||
|
||||
@ -429,6 +429,6 @@ All the "is-present" checks and the data actions for the auxiliary pointers must
|
||||
|
||||
The API relies on the primitives provided by `liboffload`, so it is provided by a new F18 runtime library, e.g. `FortranOffloadRuntime`, that depends on `FortranRuntime` and `liboffload`. The F18 driver adds `FortranOffloadRuntime` for linking under `-fopenacc`/`-fopenmp` (and maybe additional switches like `-fopenmp-targets`).
|
||||
|
||||
# TODOs:
|
||||
## TODOs:
|
||||
|
||||
* Cover the detach action.
|
||||
|
||||
@ -39,12 +39,12 @@ produce a readable version of the outputs.
|
||||
|
||||
Each detailed phase produces either correct output or fatal errors.
|
||||
|
||||
# Analysis
|
||||
## Analysis
|
||||
|
||||
This high level phase validates that the program is correct and creates all of
|
||||
the information needed for lowering.
|
||||
|
||||
## Prescan and Preprocess
|
||||
### Prescan and Preprocess
|
||||
|
||||
See [Preprocessing.md](Preprocessing.md).
|
||||
|
||||
@ -69,7 +69,7 @@ See [Preprocessing.md](Preprocessing.md).
|
||||
- `flang-new -fc1 -fdebug-dump-provenance src.f90` dumps provenance
|
||||
information
|
||||
|
||||
## Parsing
|
||||
### Parsing
|
||||
|
||||
**Input:** Cooked character stream
|
||||
|
||||
@ -85,7 +85,7 @@ representing a syntactically correct program, rooted at the program unit. See:
|
||||
- `flang-new -fc1 -fdebug-dump-parsing-log src.f90` runs an instrumented parse and dumps the log
|
||||
- `flang-new -fc1 -fdebug-measure-parse-tree src.f90` measures the parse tree
|
||||
|
||||
## Semantic processing
|
||||
### Semantic processing
|
||||
|
||||
**Input:** the parse tree, the cooked character stream, and provenance
|
||||
information
|
||||
@ -125,12 +125,12 @@ At the end of semantic processing, all validation of the user's program is compl
|
||||
- `flang-new -fc1 -fdebug-dump-symbols src.f90` dumps the symbol table
|
||||
- `flang-new -fc1 -fdebug-dump-all src.f90` dumps both the parse tree and the symbol table
|
||||
|
||||
# Lowering
|
||||
## Lowering
|
||||
|
||||
Lowering takes the parse tree and symbol table produced by analysis and
|
||||
produces LLVM IR.
|
||||
|
||||
## Create the lowering bridge
|
||||
### Create the lowering bridge
|
||||
|
||||
**Inputs:**
|
||||
- the parse tree
|
||||
@ -148,7 +148,7 @@ The lowering bridge is a container that holds all of the information needed for
|
||||
|
||||
**Entry point:** lower::LoweringBridge::create
|
||||
|
||||
## Initial lowering
|
||||
### Initial lowering
|
||||
|
||||
**Input:** the lowering bridge
|
||||
|
||||
@ -166,7 +166,7 @@ parse tree. The compiler walks the PFT generating FIR.
|
||||
- `flang-new -fc1 -fdebug-dump-pft src.f90` dumps the pre-FIR tree
|
||||
- `flang-new -fc1 -emit-mlir src.f90` dumps the FIR to the files src.mlir
|
||||
|
||||
## Transformation passes
|
||||
### Transformation passes
|
||||
|
||||
**Input:** initial version of the FIR code
|
||||
|
||||
@ -183,7 +183,7 @@ LLVM IR representation of the program.
|
||||
- `flang-new -mmlir --mlir-print-ir-after-all -S src.f90` dumps the FIR code after each pass to standard error
|
||||
- `flang-new -fc1 -emit-llvm src.f90` dumps the LLVM IR to src.ll
|
||||
|
||||
# Object code generation and linking
|
||||
## Object code generation and linking
|
||||
|
||||
After the LLVM IR is created, the flang driver invokes LLVM's existing
|
||||
infrastructure to generate object code and invoke a linker to create the
|
||||
|
||||
@ -7,7 +7,7 @@ type parameters are of integer type.
|
||||
This document aims to give insights at the representation of PDTs in FIR and how
|
||||
PDTs related constructs and features are lowered to FIR.
|
||||
|
||||
# Fortran standard
|
||||
## Fortran standard
|
||||
|
||||
Here is a list of the sections and constraints of the Fortran standard involved
|
||||
for parameterized derived types.
|
||||
@ -22,9 +22,9 @@ for parameterized derived types.
|
||||
|
||||
The constraints are implemented and tested in flang.
|
||||
|
||||
## The two types of PDTs
|
||||
### The two types of PDTs
|
||||
|
||||
### PDT with kind type parameter
|
||||
#### PDT with kind type parameter
|
||||
|
||||
PDTs with kind type parameter are already implemented in flang. Since the kind
|
||||
type parameter shall be a constant expression, it can be determined at
|
||||
@ -48,7 +48,7 @@ Lowering makes the distinction between the two types by giving them different
|
||||
names `@_QFE.kp.t.1` and `@_QFE.kp.t.2`. More information about the unique names
|
||||
can be found here: `flang/docs/BijectiveInternalNameUniquing.md`
|
||||
|
||||
### PDT with length type parameter
|
||||
#### PDT with length type parameter
|
||||
|
||||
Two PDTs with the same derived type and the same kind type parameters but
|
||||
different length type parameters are not distinct types. Unlike the kind type
|
||||
@ -92,7 +92,7 @@ two possibilities.
|
||||
These solutions have pros and cons and more details are given in the next few
|
||||
sections.
|
||||
|
||||
#### Implementing PDT with inlined components
|
||||
##### Implementing PDT with inlined components
|
||||
|
||||
In case of `len_type1`, the size, offset, etc. of `fld1` and `fld2` depend on
|
||||
the runtime values of `i` and `j` when the components are inlined into the
|
||||
@ -114,7 +114,7 @@ type len_type1(i, j)
|
||||
end type
|
||||
```
|
||||
|
||||
#### Implementing PDT with outlined components
|
||||
##### Implementing PDT with outlined components
|
||||
|
||||
A level of indirection can be used and `fld1` and `fld2` are then outlined
|
||||
as shown in `len_type2`. _compiler_allocatable_ is here only to show which
|
||||
@ -144,7 +144,7 @@ types as it could require temporaries depending how the memory is allocated.
|
||||
The outlined solution is also problematic for unformatted I/O as the
|
||||
indirections need to be followed correctly when reading or writing records.
|
||||
|
||||
#### Example of nested PDTs
|
||||
##### Example of nested PDTs
|
||||
|
||||
PDTs can be nested. Here are some example used later in the document.
|
||||
|
||||
@ -165,7 +165,7 @@ type len_type4(i, j)
|
||||
end type
|
||||
```
|
||||
|
||||
#### Example with array slice
|
||||
##### Example with array slice
|
||||
|
||||
Let's take an example with an array slice to see the advantages and
|
||||
disadvantages of the two solutions.
|
||||
@ -222,7 +222,7 @@ The size of the PDTs need to be computed at runtime. This is already the case
|
||||
for dynamic allocation sizes since it is possible for arrays to have dynamic
|
||||
shapes, etc.
|
||||
|
||||
### Support of PDTs in other compilers
|
||||
#### Support of PDTs in other compilers
|
||||
|
||||
1) Nested PDTs
|
||||
2) Array of PDTs
|
||||
@ -250,7 +250,7 @@ crash = compiler crash or runtime crash
|
||||
no = doesn't compile with no crash
|
||||
```
|
||||
|
||||
#### Field inlining in lowering
|
||||
##### Field inlining in lowering
|
||||
|
||||
A PDT with length type parameters has a list of 1 or more type parameters that
|
||||
are runtime values. These length type parameter values can be present in
|
||||
@ -373,7 +373,7 @@ computation.
|
||||
%5 = fir.field_index i, !fir.type<_QMmod1Tt{l:i32,i:!fir.array<?xi32>}>(%n : i32)
|
||||
```
|
||||
|
||||
### Length type parameter with expression
|
||||
#### Length type parameter with expression
|
||||
|
||||
The component of a PDT can be defined with expressions including the length
|
||||
type parameters.
|
||||
@ -405,7 +405,7 @@ At any place where the a PDT is initialized, the lowering would make the
|
||||
evaluation and their values saved in the addendum and pointed to by the
|
||||
descriptor.
|
||||
|
||||
### `ALLOCATE`/`DEALLOCATE` statements
|
||||
#### `ALLOCATE`/`DEALLOCATE` statements
|
||||
|
||||
The allocation and deallocation of PDTs are delegated to the runtime.
|
||||
|
||||
@ -481,7 +481,7 @@ NULLIFY(p)
|
||||
%0 = fir.call @_FortranAPointerNullifyDerived(%desc, %type) : (!fir.box<none>, !fir.tdesc) -> ()
|
||||
```
|
||||
|
||||
### Formatted I/O
|
||||
#### Formatted I/O
|
||||
|
||||
The I/O runtime internals are described in this file:
|
||||
`flang/docs/IORuntimeInternals.md`.
|
||||
@ -532,7 +532,7 @@ func.func @_QMpdtPprint_pdt() {
|
||||
}
|
||||
```
|
||||
|
||||
### Unformatted I/O
|
||||
#### Unformatted I/O
|
||||
|
||||
The entry point in the runtime for unformatted I/O is similar than the one for
|
||||
formatted I/O. A call to `_FortranAioOutputDescriptor` with the correct
|
||||
@ -540,14 +540,14 @@ descriptor is also issued by the lowering. For unformatted I/O, the runtime is
|
||||
calling `UnformattedDescriptorIO` from `flang/runtime/descriptor-io.h`.
|
||||
This function will need to be updated to support the chosen solution for PDTs.
|
||||
|
||||
### Default component initialization of local variables
|
||||
#### Default component initialization of local variables
|
||||
|
||||
Default initializers for components with length type parameters need to be
|
||||
processed as the derived type instance is created.
|
||||
The length parameters block must also be created and attached to the addendum.
|
||||
See _New f18addendum_ section for more information.
|
||||
|
||||
### Assignment
|
||||
#### Assignment
|
||||
|
||||
As mentioned in 10.2.1.2 (8), for an assignment, each length type parameter of
|
||||
the variable shall have the same value as the corresponding type parameter
|
||||
@ -586,7 +586,7 @@ the lhs, it is deallocated first and allocated with the rhs length type
|
||||
parameters information (F'2018 10.2.1.3(3)). There is code in the runtime to
|
||||
handle this already. It will need to be updated for the new f18addendum.
|
||||
|
||||
### Finalization
|
||||
#### Finalization
|
||||
|
||||
A final subroutine is called for a PDT if the subroutine has the same kind type
|
||||
parameters and rank as the entity to be finalized. The final subroutine is
|
||||
@ -643,7 +643,7 @@ type(t(kind(0.0d0))) d(n,n)
|
||||
end subroutine
|
||||
```
|
||||
|
||||
### Type parameter inquiry
|
||||
#### Type parameter inquiry
|
||||
|
||||
Type parameter inquiry is used to get the value of a type parameter in a PDT.
|
||||
|
||||
@ -677,7 +677,7 @@ a compiler generated function is used to computed its value.
|
||||
The length type parameters are indexed in declaration order; i.e., 0 is the
|
||||
first length type parameter in the deepest base type.
|
||||
|
||||
### PDTs and polymorphism
|
||||
#### PDTs and polymorphism
|
||||
|
||||
In some cases with polymorphic entities, it is necessary to copy the length
|
||||
type parameters from a descriptor to another. With the current design this is
|
||||
@ -753,7 +753,7 @@ the callee. This includes array of PDTs and derived-type with PDT components.
|
||||
The example describe one of the corner case where the length type parameter
|
||||
would be lost if the descriptor is not passed.
|
||||
|
||||
### Example that require a descriptor
|
||||
#### Example that require a descriptor
|
||||
|
||||
Because of the length type parameters store in the addendum, it is required in
|
||||
some case to pass the PDT with a descriptor to preserve the length type
|
||||
@ -816,7 +816,7 @@ end
|
||||
Because of the use case described above, PDTs, array of PDTs or derived-type
|
||||
with PDT components will be passed by descriptor.
|
||||
|
||||
## FIR operations with length type parameters
|
||||
### FIR operations with length type parameters
|
||||
|
||||
Couple of operations have length type parameters as operands already in their
|
||||
design. For some operations, length type parameters are likely needed with
|
||||
@ -827,7 +827,7 @@ parameters are in it.
|
||||
The operations will be updated if needed during the implementation of the
|
||||
chosen solution.
|
||||
|
||||
### `fir.alloca`
|
||||
#### `fir.alloca`
|
||||
|
||||
This primitive operation is used to allocate an object on the stack. When
|
||||
allocating a PDT, the length type parameters are passed to the
|
||||
@ -840,7 +840,7 @@ operation so its size can be computed accordingly.
|
||||
// %i is the ssa value of the length type parameter
|
||||
```
|
||||
|
||||
### `fir.allocmem`
|
||||
#### `fir.allocmem`
|
||||
|
||||
This operation is used to create a heap memory reference suitable for storing a
|
||||
value of the given type. When creating a PDT, the length type parameters are
|
||||
@ -854,7 +854,7 @@ passed so the size can be computed accordingly.
|
||||
fir.freemem %0 : !fir.type<_QMmod1Tpdt{i:i32,data:!fir.array<?xf32>}>
|
||||
```
|
||||
|
||||
### `fir.embox`
|
||||
#### `fir.embox`
|
||||
|
||||
The `fir.embox` operation create a boxed reference value. In the case of PDTs
|
||||
the length type parameters can be passed as well to the operation.
|
||||
@ -887,7 +887,7 @@ func.func @_QMpdt_initPlocal() {
|
||||
}
|
||||
```
|
||||
|
||||
### `fir.field_index`
|
||||
#### `fir.field_index`
|
||||
|
||||
The `fir.field_index` operation is used to generate a field offset value from
|
||||
a field identifier in a derived-type. The operation takes length type parameter
|
||||
@ -902,7 +902,7 @@ values with a PDT so it can compute a correct offset.
|
||||
return %3
|
||||
```
|
||||
|
||||
### `fir.len_param_index`
|
||||
#### `fir.len_param_index`
|
||||
|
||||
This operation is used to get the length type parameter offset in from a PDT.
|
||||
|
||||
@ -916,7 +916,7 @@ func.func @_QPpdt_len_value(%arg0: !fir.box<!fir.type<t1{l:i32,!fir.array<?xi32>
|
||||
}
|
||||
```
|
||||
|
||||
### `fir.save_result`
|
||||
#### `fir.save_result`
|
||||
|
||||
Save the result of a function returning an array, box, or record type value into
|
||||
a memory location given the shape and LEN parameters of the result. Length type
|
||||
@ -933,7 +933,7 @@ func.func @return_pdt(%buffer: !fir.ref<!fir.type<t2(l1:i32,l2:i32){x:f32}>>) {
|
||||
}
|
||||
```
|
||||
|
||||
### `fir.array_*` operations
|
||||
##### `fir.array_*` operations
|
||||
|
||||
The current design of the different `fir.array_*` operations include length type
|
||||
parameters operands. This is designed to use PDT without descriptor directly in
|
||||
@ -952,7 +952,7 @@ FIR.
|
||||
|
||||
---
|
||||
|
||||
## Implementation choice
|
||||
### Implementation choice
|
||||
|
||||
While both solutions have pros and cons, we want to implement the outlined
|
||||
solution.
|
||||
@ -961,7 +961,7 @@ solution.
|
||||
|
||||
---
|
||||
|
||||
# Testing
|
||||
## Testing
|
||||
|
||||
- Lowering part is tested with LIT tests in tree
|
||||
- PDTs involved a lot of runtime information so executable
|
||||
@ -969,7 +969,7 @@ solution.
|
||||
|
||||
---
|
||||
|
||||
# Current TODOs
|
||||
## Current TODOs
|
||||
Current list of TODOs in lowering:
|
||||
- `flang/lib/Lower/Allocatable.cpp:461` not yet implement: derived type length parameters in allocate
|
||||
- `flang/lib/Lower/Allocatable.cpp:645` not yet implement: deferred length type parameters
|
||||
|
||||
@ -874,7 +874,7 @@ dynamic type of polymorphic entities.
|
||||
```
|
||||
---
|
||||
|
||||
# Testing
|
||||
## Testing
|
||||
|
||||
- Lowering part is tested with LIT tests in tree
|
||||
- Polymorphic entities involved a lot of runtime information so executable
|
||||
@ -882,7 +882,7 @@ dynamic type of polymorphic entities.
|
||||
|
||||
---
|
||||
|
||||
# Current TODOs
|
||||
## Current TODOs
|
||||
Current list of TODOs in lowering:
|
||||
- `flang/lib/Lower/Bridge.cpp:448` not yet implemented: create polymorphic host associated copy
|
||||
- `flang/lib/Lower/CallInterface.cpp:795` not yet implemented: support for polymorphic types
|
||||
|
||||
@ -422,7 +422,7 @@ func.func @proc_pointer_component(%arg0 : !fir.boxproc<(!fir.ref<i32>) -> f32>,
|
||||
|
||||
---
|
||||
|
||||
# Testing
|
||||
## Testing
|
||||
|
||||
The lowering part is tested with LIT tests in tree, but the execution tests are
|
||||
useful for full testing.
|
||||
@ -452,7 +452,7 @@ The tests should include the following
|
||||
|
||||
---
|
||||
|
||||
# Current TODOs
|
||||
## Current TODOs
|
||||
Current list of TODOs in lowering:
|
||||
- `flang/lib/Lower/CallInterface.cpp:708`: not yet implemented: procedure pointer result not yet handled
|
||||
- `flang/lib/Lower/CallInterface.cpp:961`: not yet implemented: procedure pointer arguments
|
||||
|
||||
@ -95,15 +95,12 @@ pygments_style = "friendly"
|
||||
|
||||
# The theme to use for HTML and HTML Help pages. See the documentation for
|
||||
# a list of builtin themes.
|
||||
html_theme = "llvm-theme"
|
||||
html_theme = "haiku"
|
||||
|
||||
# Theme options are theme-specific and customize the look and feel of a theme
|
||||
# further. For a list of options available for each theme, see the
|
||||
# documentation.
|
||||
html_theme_options = {"nosidebar": False}
|
||||
|
||||
# Add any paths that contain custom themes here, relative to this directory.
|
||||
html_theme_path = ["_themes"]
|
||||
# html_theme_options = {}
|
||||
|
||||
# Add any paths that contain custom themes here, relative to this directory.
|
||||
# html_theme_path = []
|
||||
@ -127,11 +124,7 @@ html_title = "The Flang Compiler"
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
html_static_path = ["_static"]
|
||||
|
||||
html_context = {
|
||||
"css_files": ["_static/llvm.css"],
|
||||
}
|
||||
# html_static_path = []
|
||||
|
||||
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
|
||||
# using the given strftime format.
|
||||
@ -142,13 +135,7 @@ html_last_updated_fmt = "%b %d, %Y"
|
||||
# html_use_smartypants = True
|
||||
|
||||
# Custom sidebar templates, maps document names to template names.
|
||||
html_sidebars = {
|
||||
"**": [
|
||||
"indexsidebar.html",
|
||||
"searchbox.html",
|
||||
]
|
||||
}
|
||||
|
||||
# html_sidebars = {}
|
||||
|
||||
# Additional templates that should be rendered to pages, maps page names to
|
||||
# template names.
|
||||
|
||||
@ -66,6 +66,7 @@ on how to get in touch with us and to learn more about the current status.
|
||||
LabelResolution
|
||||
ModFiles
|
||||
OpenACC
|
||||
OpenACC-descriptor-management.md
|
||||
OpenMP-4.5-grammar.md
|
||||
OpenMP-semantics
|
||||
OptionComparison
|
||||
@ -87,6 +88,5 @@ on how to get in touch with us and to learn more about the current status.
|
||||
|
||||
```{eval-rst}
|
||||
* :ref:`genindex`
|
||||
* :ref:`modindex`
|
||||
* :ref:`search`
|
||||
```
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user