Support for target specific lowering in the Tilikum bridge. #413
Conversation
To generate correct code for a chosen target, the Tilikum bridge must know what the selected target is and the conventions used for the specific target ABI. The properties of the target influence the calling conventions and LLVM IR that must be generated. Tilikum is the last point before any high-level abstractions must be considered and correctly translated to LLVM IR. These changed rework the Tilikum bridge to use a target specifier and convert the calling conventions and memory layouts appropriate for the selected target. Two target specifications are implemented. i386-unknown-linux-gnu and x86_64-unknown-linux-gnu. Others can be added as needed. Two high-level type abstractions are considered: COMPLEX and CHARACTER. Moving these target specific lowerings to a common place in code gen eliminates the need to perform heroics with custom code in lowering and/or reliance on assuming the target is known by implication at compiler compile-time.
|
That is great to have all this in the Optimizer, thanks for adding this ! |
| }); | ||
| addConversion( | ||
| [&](mlir::ComplexType cmplx) { return convertComplexType(cmplx); }); | ||
| addConversion( |
There was a problem hiding this comment.
convertComplexType added twice ?
There was a problem hiding this comment.
There are two distinct types. mlir::ComplexType and fir::ComplexType.
|
|
||
| /// Taking the address of a function. Modify the signature as needed. | ||
| void convertAddrOp(AddrOfOp addrOp) { | ||
| auto addrTy = addrOp.getType().cast<mlir::FunctionType>(); |
There was a problem hiding this comment.
Do you think the part related to FunctionType conversion could be shared with the similar processing in convertSignature ?
There was a problem hiding this comment.
Good point. I'll take a look.
| // split format with all pointers first (in the declared position) and all | ||
| // LEN arguments appended after all of the dummy arguments. | ||
| // NB: Other conventions/ABIs can/should be supported via options. | ||
| marshal.emplace_back(idxTy, AT{0, {}, {}, /*append=*/!sret}); |
There was a problem hiding this comment.
So far the returned charbox were already passed as split argument in lowering, that make sens to update this to use what you are doing here. However, character returns are caller allocated, I saw in your change that there is a FixupTy::Codes::ReturnAsStore that seems to allocate the return on the callee side, is it possible to insert allocation on caller side for character returns or should lowering still take care of this ?
There was a problem hiding this comment.
A Fortran function that returns a CHARACTER value is intended (modulo my bugs) to be passed as a SRET argument of Boxchar type. That means the caller has to pass (and allocate) the space and pass the LEN value. This differs from a non-SRET Boxchar argument in how the argument is ordered in the signature only. The called function should play no role in allocating space for the result (or arguments).
| /// modifies a signature per a particular ABI's calling convention. | ||
| /// Note: llvm::Attribute is not used directly, because its use depends on an | ||
| /// LLVMContext. | ||
| class Attributes { |
There was a problem hiding this comment.
Are these attributes meant to be added/used by the Optimizer only or should lowering already create add some of these ?
There was a problem hiding this comment.
These are intended to be used for lowering to LLVM.
The one caveat is with a FUNCTION return a CHARACTER type. Lowering must distinguish between a plain old argument and the return value being returned through an argument.
That's not to discourage taking broader advantage of argument attributes in lowering in any way. Special alignments, dealing with generalized descriptors, etc. may create wider opportunities.
There was a problem hiding this comment.
Thanks the explanation, I now see what I see what I need to update to take advantage of this in the bridge.
fix a few bugs
|
This fixes issue #344 . |
flang-compiler#413 Differential Revision: https://reviews.llvm.org/D96072
This patch adds support for `!fir.vector`, a rank one, constant length data type. flang-compiler#413 Differential Revision: https://reviews.llvm.org/D96162
This patch adds support for `!fir.vector`, a rank one, constant length data type. flang-compiler/f18-llvm-project#413 Differential Revision: https://reviews.llvm.org/D96162
To generate correct code for a chosen target, the Tilikum bridge must know
what the selected target is and the conventions used for the specific target
ABI. The properties of the target influence the calling conventions and LLVM
IR that must be generated. Tilikum is the last point before any high-level
abstractions must be considered and correctly translated to LLVM IR.
These changed rework the Tilikum bridge to use a target specifier and convert
the calling conventions and memory layouts appropriate for the selected target.
Two target specifications are implemented. i386-unknown-linux-gnu and
x86_64-unknown-linux-gnu. Others can be added as needed.
Two high-level type abstractions are considered: COMPLEX and CHARACTER.
Moving these target specific lowerings to a common place in code gen eliminates
the need to perform heroics with custom code in lowering and/or reliance on
assuming the target is known by implication at compiler compile-time.