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.
116 lines
4.4 KiB
C++
116 lines
4.4 KiB
C++
//===--- GenFunc.h - Swift IR generation for functions ----------*- 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 provides the private interface to the function and
|
|
// function-type emission code.
|
|
//
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#ifndef SWIFT_IRGEN_GENFUNC_H
|
|
#define SWIFT_IRGEN_GENFUNC_H
|
|
|
|
#include "CallingConvention.h"
|
|
|
|
namespace clang {
|
|
template <class> class CanQual;
|
|
class Type;
|
|
}
|
|
|
|
namespace swift {
|
|
class ApplyInst;
|
|
class FuncDecl;
|
|
enum class ResilienceExpansion : unsigned;
|
|
class SILParameterInfo;
|
|
class Substitution;
|
|
class SILType;
|
|
|
|
namespace irgen {
|
|
class Address;
|
|
class Alignment;
|
|
class Explosion;
|
|
class ForeignFunctionInfo;
|
|
class IRGenFunction;
|
|
class LoadableTypeInfo;
|
|
class TypeInfo;
|
|
|
|
/// Should the given self parameter be given the special treatment
|
|
/// for self parameters?
|
|
bool isSelfContextParameter(SILParameterInfo parameter);
|
|
|
|
/// Emit a partial application thunk for a function pointer applied to a
|
|
/// partial set of argument values.
|
|
void emitFunctionPartialApplication(IRGenFunction &IGF,
|
|
llvm::Value *fnPtr,
|
|
llvm::Value *fnContext,
|
|
Explosion &args,
|
|
ArrayRef<SILParameterInfo> argTypes,
|
|
ArrayRef<Substitution> subs,
|
|
CanSILFunctionType origType,
|
|
CanSILFunctionType substType,
|
|
CanSILFunctionType outType,
|
|
Explosion &out);
|
|
|
|
/// Add function attributes to an attribute set for a byval argument.
|
|
void addByvalArgumentAttributes(IRGenModule &IGM,
|
|
llvm::AttributeSet &attrs,
|
|
unsigned argIndex,
|
|
Alignment align);
|
|
|
|
/// Add signext or zeroext attribute set for an argument that needs
|
|
/// extending.
|
|
void addExtendAttribute(IRGenModule &IGM, llvm::AttributeSet &attrs,
|
|
unsigned index, bool signExtend);
|
|
|
|
/// Emit a call to a builtin function.
|
|
void emitBuiltinCall(IRGenFunction &IGF, Identifier FnId,
|
|
SILType resultType,
|
|
Explosion &args, Explosion &result,
|
|
ArrayRef<Substitution> substitutions);
|
|
|
|
/// Project the capture address from on-stack block storage.
|
|
Address projectBlockStorageCapture(IRGenFunction &IGF,
|
|
Address storageAddr,
|
|
CanSILBlockStorageType storageTy);
|
|
|
|
/// Emit the block header into a block storage slot.
|
|
void emitBlockHeader(IRGenFunction &IGF,
|
|
Address storage,
|
|
CanSILBlockStorageType blockTy,
|
|
llvm::Function *invokeFunction,
|
|
CanSILFunctionType invokeTy,
|
|
ForeignFunctionInfo foreignInfo);
|
|
|
|
/// Can a series of values be simply pairwise coerced to (or from) an
|
|
/// explosion schema, or do they need to traffic through memory?
|
|
bool canCoerceToSchema(IRGenModule &IGM,
|
|
ArrayRef<llvm::Type*> types,
|
|
const ExplosionSchema &schema);
|
|
|
|
void emitClangExpandedParameter(IRGenFunction &IGF,
|
|
Explosion &in, Explosion &out,
|
|
clang::CanQual<clang::Type> clangType,
|
|
SILType swiftType,
|
|
const LoadableTypeInfo &swiftTI);
|
|
|
|
/// Allocate a stack buffer of the appropriate size to bitwise-coerce a value
|
|
/// between two LLVM types.
|
|
std::pair<Address, Size>
|
|
allocateForCoercion(IRGenFunction &IGF,
|
|
llvm::Type *fromTy,
|
|
llvm::Type *toTy,
|
|
const llvm::Twine &basename);
|
|
|
|
} // end namespace irgen
|
|
} // end namespace swift
|
|
|
|
#endif
|