diff options
| author | Jean Perier <jperier@nvidia.com> | 2022-02-02 09:21:44 +0100 |
|---|---|---|
| committer | Jean Perier <jperier@nvidia.com> | 2022-02-02 09:22:11 +0100 |
| commit | c099ca4e45dbccd58dfa1964fa1f304c6055958d (patch) | |
| tree | b7227255485f8ebe52a7bfc52c233f275d8ea79b /llvm/tools/llvm-reduce/DeltaManager.cpp | |
| parent | 7d926b71775418d2c0c1e529ab72f811507895fa (diff) | |
| download | llvm-c099ca4e45dbccd58dfa1964fa1f304c6055958d.zip llvm-c099ca4e45dbccd58dfa1964fa1f304c6055958d.tar.gz llvm-c099ca4e45dbccd58dfa1964fa1f304c6055958d.tar.bz2 | |
[flang][optimizer] support aggregate types inside tuple and record type
This patch allows:
- fir.box type to be a member of tuple<> or fir.type<> types,
- tuple<> type to be a member of tuple<> type.
When a fir.box types are nested in tuple<> or fir.type<>, it is translated
to the struct type of a Fortran runtime descriptor, and not a
pointer to a descriptor. This is because the fir.box is owned by the tuple
or fir.type.
FIR type translation was also flattening nested tuple while lowering to LLVM
dialect types. There does not seem to be a deep reason for doing that
and doing it causes issues in fir.coordinate_of generated on such tuple
(a fir.coordinate_of getting tuple<B, C> in tuple<A, tuple<B, C>>
ended-up lowered to an LLVM GEP getting B).
Differential Revision: https://reviews.llvm.org/D118701
Diffstat (limited to 'llvm/tools/llvm-reduce/DeltaManager.cpp')
0 files changed, 0 insertions, 0 deletions