An address projection instruction is one of the following instructions:
1. struct_element_addr.
2. tuple_element_addr.
3. ref_element_addr.
This method takes in the given SILValue and continually searches up its
operand chain until it finds a non address projection, non-cast
value (where cast is defined as in SILValue::stripCasts()). The found
SILValue is then returned.
Swift SVN r12909
This method takes in a SILValue and returns the SILValue created by continually
moving up the operand chain of the SILValue until a non-cast instruction is hit.
The non-cast instruction is then returned.
Swift SVN r12906
This reverts commit r12749.
I did not know about the connection in between VALUE_RANGES and abstract SIL
Base types. Using those you can perform the same operation via the isa
operation.
Swift SVN r12763
Thus if one wishes to match a method inst, instead of using a switch one could
just go isMethodInst(Kind) and get the appropriate result.
My hope is this will make life easier by allowing us to use less switches.
Swift SVN r12749
Reuse John's abstraction thunking machinery in SILGenPoly to emit the abstraction change from a protocol requirement to a concrete witness. There are potentially two abstraction changes necessary; if a witness is generic, we need to reabstract again from the concrete substituted type of the witness to the generic witness function's original signature. This currently leads to a bunch of extra temporaries in cases where an argument or return gets unabstracted to a loadable value then reabstracted to a generic parameter, but optimizations should be able to clean this up. Protocol witnesses also have additional potential abstraction changes in their 'self' parameter: the 'self' parameter of the protocol requirement is always considered @inout, but class 'self' parameters are not; also, an operator requirement can be satisfied by a free function, in which case 'self' is discarded.
Also, fix a bug in return value thunking where, if the thunk could reuse its @out parameter as the @out parameter of the underlying function, we would not disable the cleanup we install on the result value, leading to the result getting overreleased.
Swift SVN r11245
a value that still has uses. Doing so leaves dangling pointers and is
unwise. Nothing in the testsuite triggers this, but simplify-cfg can
on real code.
Swift SVN r9770
There are no values other than instructions that can use other values. BBArguments are
defs, not uses. This eliminates a bunch of casts in clients that use getUser().
Swift SVN r9701
Make ApplyInst and PartialApplyInst directly take substitutions for generic functions instead of trying to stage out substitutions separately. The legacy reasons for doing this are gone.
Swift SVN r8747
I’ve added it without understanding the full consequences. If a variant of this is added, it
should take a list of values as the argument. Currently, there is no use for it, so just remove it.
Swift SVN r7238
Remove uncurry level as a property of SILType/SILFunctionTypeInfo. During SIL type lowering, map a (Type, UncurryLevel) pair to a Swift CanType with the uncurried arguments as a Swift tuple. For example, T -> (U, V) -> W at uncurry level 1 becomes ((U, V), T) -> W--in reverse order to match the low-level calling convention. Update SILGen and IRGen all over the place for this representation change.
SILFunctionTypeInfo is still used in the SILType representation, but it's no longer load-bearing. Everything remaining in it can be derived from a Swift type.
This is an ABI break. Be sure to rebuild clean!
Swift SVN r5296
This frees up an extra bit in SILType, which we can expose to LLVM through
PointerLikeTypeTraits. Use this bit in a PointerUnion, which allows simplifying
ValueBase, which happened to be the last use of the isInvalid() state.
Swift SVN r5218
Replace 'constant_ref' with 'function_ref', which references a SILFunction directly, and 'global_addr', which references a global variable VarDecl. Get rid of the SILConstant-to-SILFunction mapping in SILModule and replace it with an ilist of SILFunctions. Allow SILFunctions to be 'external' by not having any blocks in their body.
For now, SILFunctions still carry around their SILConstant "name", because name mangling and IRGen still rely on access to the original decl in order to recover IRGen information, which unfortunately leaves IRGen's CodeRefs in a gross, awkward intermediate state. Lifting mangling, AbstractCC, and other linkage attributes to SIL should clear up this up.
Swift SVN r4865
When lowering SIL builtin ConstantRefs, just stash away the FuncDecl, and pass that decl on to a tweaked version of emitBuiltinCall when the constant is applied.
Swift SVN r4736
take a const ValueBase* instead of a SILValue, implement SILArgument
cases for a few visitors and opt others out explicitly, and assert
that classes in the SIL value hierarchy override their superclass's
classof.
Swift SVN r4705
