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.
65 lines
2.6 KiB
C++
65 lines
2.6 KiB
C++
//===--- ValueTracking.h - SIL Value Tracking Analysis ----------*- 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 contains routines which analyze chains of computations.
|
|
//
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#ifndef SWIFT_SILOPTIMIZER_ANALYSIS_VALUETRACKING_H
|
|
#define SWIFT_SILOPTIMIZER_ANALYSIS_VALUETRACKING_H
|
|
|
|
#include "swift/SIL/SILArgument.h"
|
|
#include "swift/SIL/SILInstruction.h"
|
|
|
|
namespace swift {
|
|
|
|
/// Returns true if \p V is a function argument which may not alias to
|
|
/// any other pointer in the function.
|
|
/// The \p assumeInoutIsNotAliasing specifies in no-aliasing is assumed for
|
|
/// the @inout convention. See swift::isNotAliasedIndirectParameter().
|
|
bool isNotAliasingArgument(SILValue V, InoutAliasingAssumption isInoutAliasing =
|
|
InoutAliasingAssumption::Aliasing);
|
|
|
|
/// Returns true if \p V is local inside its function. This means its underlying
|
|
/// object either is a non-aliasing function argument or a locally allocated
|
|
/// object.
|
|
/// The \p assumeInoutIsNotAliasing specifies in no-aliasing is assumed for
|
|
/// the @inout convention. See swift::isNotAliasedIndirectParameter().
|
|
bool pointsToLocalObject(SILValue V, InoutAliasingAssumption isInoutAliasing =
|
|
InoutAliasingAssumption::Aliasing);
|
|
|
|
enum class IsZeroKind {
|
|
Zero,
|
|
NotZero,
|
|
Unknown
|
|
};
|
|
|
|
/// Check if the value \p Value is known to be zero, non-zero or unknown.
|
|
IsZeroKind isZeroValue(SILValue Value);
|
|
|
|
/// Checks if a sign bit of a value is known to be set, not set or unknown.
|
|
/// Essentially, it is a simple form of a range analysis.
|
|
/// This approach is inspired by the corresponding implementation of
|
|
/// ComputeSignBit in LLVM's value tracking implementation.
|
|
/// It is planned to extend this approach to track all bits of a value.
|
|
/// Therefore it can be considered to be the beginning of a range analysis
|
|
/// infrastructure for the Swift compiler.
|
|
Optional<bool> computeSignBit(SILValue Value);
|
|
|
|
/// Check if execution of a given builtin instruction can result in overflows.
|
|
/// Returns true of an overflow can happen. Otherwise returns false.
|
|
bool canOverflow(BuiltinInst *BI);
|
|
|
|
} // end namespace swift
|
|
|
|
#endif // SWIFT_SILOPTIMIZER_ANALYSIS_VALUETRACKING_H
|