mirror of
https://github.com/apple/swift.git
synced 2025-12-14 20:36:38 +01:00
e249fd680e
Similarly to how we've always handled parameter types, we now recursively expand tuples in result types and separately determine a result convention for each result. The most important code-generation change here is that indirect results are now returned separately from each other and from any direct results. It is generally far better, when receiving an indirect result, to receive it as an independent result; the caller is much more likely to be able to directly receive the result in the address they want to initialize, rather than having to receive it in temporary memory and then copy parts of it into the target. The most important conceptual change here that clients and producers of SIL must be aware of is the new distinction between a SILFunctionType's *parameters* and its *argument list*. The former is just the formal parameters, derived purely from the parameter types of the original function; indirect results are no longer in this list. The latter includes the indirect result arguments; as always, all the indirect results strictly precede the parameters. Apply instructions and entry block arguments follow the argument list, not the parameter list. A relatively minor change is that there can now be multiple direct results, each with its own result convention. This is a minor change because I've chosen to leave return instructions as taking a single operand and apply instructions as producing a single result; when the type describes multiple results, they are implicitly bound up in a tuple. It might make sense to split these up and allow e.g. return instructions to take a list of operands; however, it's not clear what to do on the caller side, and this would be a major change that can be separated out from this already over-large patch. Unsurprisingly, the most invasive changes here are in SILGen; this requires substantial reworking of both call emission and reabstraction. It also proved important to switch several SILGen operations over to work with RValue instead of ManagedValue, since otherwise they would be forced to spuriously "implode" buffers.
132 lines
4.1 KiB
C++
132 lines
4.1 KiB
C++
//===--- Callee.h - Information about a physical callee ---------*- C++ -*-===//
|
|
//
|
|
// This source file is part of the Swift.org open source project
|
|
//
|
|
// Copyright (c) 2014 - 2016 Apple Inc. and the Swift project authors
|
|
// Licensed under Apache License v2.0 with Runtime Library Exception
|
|
//
|
|
// See http://swift.org/LICENSE.txt for license information
|
|
// See http://swift.org/CONTRIBUTORS.txt for the list of Swift project authors
|
|
//
|
|
//===----------------------------------------------------------------------===//
|
|
//
|
|
// This file defines the Callee type, which stores all necessary
|
|
// information about a physical callee.
|
|
//
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#ifndef SWIFT_IRGEN_CALLEE_H
|
|
#define SWIFT_IRGEN_CALLEE_H
|
|
|
|
#include <type_traits>
|
|
#include "llvm/IR/DerivedTypes.h"
|
|
#include "swift/SIL/SILType.h"
|
|
#include "CallingConvention.h"
|
|
#include "Explosion.h"
|
|
#include "IRGen.h"
|
|
|
|
namespace llvm {
|
|
class PointerType;
|
|
}
|
|
|
|
namespace clang {
|
|
namespace CodeGen {
|
|
class CGFunctionInfo;
|
|
}
|
|
}
|
|
|
|
namespace swift {
|
|
class Substitution;
|
|
|
|
namespace irgen {
|
|
class Callee;
|
|
class IRGenFunction;
|
|
|
|
class ForeignFunctionInfo {
|
|
public:
|
|
const clang::CodeGen::CGFunctionInfo *ClangInfo = nullptr;
|
|
};
|
|
|
|
class Callee {
|
|
/// The unsubstituted function type being called.
|
|
CanSILFunctionType OrigFnType;
|
|
|
|
/// The substituted result type of the function being called.
|
|
CanSILFunctionType SubstFnType;
|
|
|
|
/// The clang information for the function being called, if applicable.
|
|
ForeignFunctionInfo ForeignInfo;
|
|
|
|
/// The pointer to the actual function.
|
|
llvm::Value *FnPtr;
|
|
|
|
/// The data pointer required by the function. There's an
|
|
/// invariant that this never stores an llvm::ConstantPointerNull.
|
|
llvm::Value *DataPtr;
|
|
|
|
/// The archetype substitutions under which the function is being
|
|
/// called.
|
|
std::vector<Substitution> Substitutions;
|
|
|
|
public:
|
|
Callee() = default;
|
|
|
|
/// Prepare a callee for a known function with a known data pointer.
|
|
static Callee forKnownFunction(CanSILFunctionType origFnType,
|
|
CanSILFunctionType substFnType,
|
|
ArrayRef<Substitution> subs,
|
|
llvm::Value *fn, llvm::Value *data,
|
|
ForeignFunctionInfo foreignInfo) {
|
|
// Invariant on the function pointer.
|
|
assert(fn->getType()->getPointerElementType()->isFunctionTy());
|
|
assert((foreignInfo.ClangInfo != nullptr) ==
|
|
(origFnType->getLanguage() == SILFunctionLanguage::C));
|
|
|
|
Callee result;
|
|
result.OrigFnType = origFnType;
|
|
result.SubstFnType = substFnType;
|
|
result.FnPtr = fn;
|
|
result.DataPtr = data;
|
|
result.Substitutions = subs;
|
|
result.ForeignInfo = foreignInfo;
|
|
return result;
|
|
}
|
|
|
|
SILFunctionTypeRepresentation getRepresentation() const {
|
|
return OrigFnType->getRepresentation();
|
|
}
|
|
|
|
CanSILFunctionType getOrigFunctionType() const { return OrigFnType; }
|
|
CanSILFunctionType getSubstFunctionType() const { return SubstFnType; }
|
|
|
|
bool hasSubstitutions() const { return !Substitutions.empty(); }
|
|
ArrayRef<Substitution> getSubstitutions() const { return Substitutions; }
|
|
|
|
llvm::Value *getFunction() const { return FnPtr; }
|
|
|
|
llvm::FunctionType *getLLVMFunctionType() {
|
|
return cast<llvm::FunctionType>(FnPtr->getType()->getPointerElementType());
|
|
}
|
|
|
|
const ForeignFunctionInfo &getForeignInfo() const {
|
|
return ForeignInfo;
|
|
}
|
|
|
|
/// Return the function pointer as an i8*.
|
|
llvm::Value *getOpaqueFunctionPointer(IRGenFunction &IGF) const;
|
|
|
|
/// Return the function pointer as an appropriate pointer-to-function.
|
|
llvm::Value *getFunctionPointer() const { return FnPtr; }
|
|
|
|
/// Is it possible that this function requires a non-null data pointer?
|
|
bool hasDataPointer() const { return DataPtr != nullptr; }
|
|
|
|
/// Return the data pointer as a %swift.refcounted*.
|
|
llvm::Value *getDataPointer(IRGenFunction &IGF) const;
|
|
};
|
|
|
|
} // end namespace irgen
|
|
} // end namespace swift
|
|
|
|
#endif
|