Upstream clang got better about preserving the type of lowered vector parameters, so float_vec3 lowers to a <3 x float> parameter rather than a generic <2 x double>. We still represent the opaque blob as an aligned i128, since we don't understand padding in imported structs, so we need to generalize coerceValue to deal with size mismatches in both directions. Fixes rdar://problem/20011424.
Swift SVN r25701
Clean up the messy code for putting byval arguments at the right argument index; we don't pretend to handle multiple uncurry levels in IRGen anymore, so we can just use the absolute index of lowered arguments for attribute indices. Add zeroext/signext attributes as needed for small integer arguments in calls. Fixes rdar://problem/19455987.
Swift SVN r25687
In partial apply forwarding thunks, we need to cast dependent result types of
polymorphic function calls to the specialized type.
For example for:
%0 = function_ref @closure :
$@thin <C where C : Base> (@owned Base) -> @owned C
%1 = partial_apply %0<Sub>() :
$@thin <C where C : Base> (@owned Base) -> @owned C
We need to cast the result type:
define %C3Sub* @_TPA_closure(%C4Base*) {
entry:
%1 = call %swift.type* @_TMaC3Sub()
%2 = tail call %C4Base* @closure(%C4Base* %0, %swift.type* %1)
--> %3 = bitcast %C4Base* %2 to %C3Sub*
ret %C3Sub* %3
}
rdar://19930705
Swift SVN r25521
When forming a closure over a dynamic function value, we were failing to set sret, byval, etc. attributes on the call of the underlying function in the partial application thunk. Fixes rdar://problem/19875360.
Swift SVN r25387
was incomplete; we do use it on i386 for arbitrary small
aggregates, and unfortunately this means we have to learn
how to expand quite a lot of types.
Tested by the i386-simulator build. I still think
we can completely remove this code relatively soon.
Swift SVN r24981
the C calling convention.
You might notice the absence of tests. Older versions of Clang
used Expand for ARM64 homogeneous aggregates. Trunk Clang no
longer does this, and indeed, on Apple platforms we no longer
use Expand to pass any kind of argument at all. The only target
in trunk that uses it is the Windows target's vectorcall
alternative CC, which I have no way to convince Swift to
generate a call against. Therefore this code is completely
dead in trunk, and thus untestable.
Removing Expand completely from Clang would be the ideal solution,
but that's politically tricky because this is a part of Clang
that's frequently edited by people supporting out-of-tree backends.
I've started the process, but until then, if we're going to have
dead code, it ought to at least be correct dead code.
This commit fixes rdar://19199427, or at least it will
when it's merged to branches that actually use Expand.
Swift SVN r24949
Per the previous commit we are no longer using this. Minor save in
simplicity and maybe a bit of compilation time as well.
In the long run IRGen probably shouldn't be pulling information from the
AST at all; the SILModule should be able to tell it what types it needs
to emit information for. But this is still an improvement for now.
No functionality change (that was the previous commit).
Swift SVN r24840
Instead, just fall through to the normal public/internal/private switch
added in the previous commit. Local declarations are always private.
Make sure we emit all local declarations by using the list in the SourceFile,
rather than walking the AST (which missed a few cases and was less efficient
anyway).
As an exception, declarations without accessibility at all still get private
linkage. These are things like local variables that don't get accessed by
symbol, even when using the debugger.
rdar://problem/19623016
Swift SVN r24839
OpaqueStorageTypeInfo uses iNNN types that don't always have the correct alloc size for an expected
size at the LLVM level. This needs to be fixed before my partial apply closure fixes can hold.
Swift SVN r24551
In order to deal with generic indirect value captures, we need to be able to bind their type metadata in the partial apply forwarder and heap object destructor to have access to the value operations for that type. NecessaryBindings gives us a way to do that and clean up our ad-hoc polymorphic argument forwarding we had before. N(intended)FC yet, aside from some harmless reordering of operations, since we also need to implement NonFixedOffsets for heap objects to be fully operational.
Swift SVN r24526
Until now, we treated all value parameters as +1, and all indirect parameters as +0 by reference, which is totally bogus. Now that we'll be partially applying guaranteed parameters, for instance to implement SomeType.foo curried method references, we need to get this right.
This breaks curries that capture dependent-layout parameters by value, but they were already broken due to us treating them as 'inout' captures. I'll fix this by adding NecessaryBindings and NonFixedOffsets to HeapLayout next.
Swift SVN r24475
Teach IRGen and the runtime about the extra inhabitants
of function pointers, and take advantage of that in
thin and thick function types.
Also add runtime entrypoints for thin function type
metadata.
Swift SVN r24346
IRGen uses a typedef, SpareBitVector, for its principal
purpose of tracking spare bits. Other uses should not
use this typedef, and I've tried to follow that, but I
did this rewrite mostly with sed and may have missed
some fixups.
This should be almost completely NFC. There may be
some subtle changes in spare bits for witness tables
and other off-beat pointer types. I also fixed a bug
where IRGen thought that thin functions were two
pointers wide, but this wouldn't have affected anything
because we never store thin functions anyway, since
they're not a valid AST type.
This commit repplies r24305 with two fixes:
- It fixes the computation of spare bits for unusual
integer types to use the already-agreed-upon type
size instead of recomputing it. This fixes the
i386 stdlib build. Joe and I agreed that we should
also change the size to use the LLVM alloc size
instead of the next power of 2, but this patch
does not do that yet.
- It changes the spare bits in function types back
to the empty set. I'll be changing this in a
follow-up, but it needs to be tied to runtime
changes. This fixes the regression test failures.
Swift SVN r24324
IRGen uses a typedef, SpareBitVector, for its principal
purpose of tracking spare bits. Other uses should not
use this typedef, and I've tried to follow that, but I
did this rewrite mostly with sed and may have missed
some fixups.
This should be almost completely NFC. There may be
some subtle changes in spare bits for witness tables
and other off-beat pointer types. I also fixed a bug
where IRGen thought that thin functions were two
pointers wide, but this wouldn't have affected anything
because we never store thin functions anyway, since
they're not a valid AST type.
Swift SVN r24305
This happens with GLKVector3 on x86_64, whose ABI type is { <2 x float>, float }, which LLVM considers to have 16 bytes size due to alignment, but has a storage type of { float, float, float }. Relax the assertion that the coerced type is exactly the same size as the storage type.
Swift SVN r23888
isn't used yet, but will be for modeling the self argument passed to an
address-only witness implementation. NFC since all this code is dead :-)
Swift SVN r23857
If an imported C struct has no __nonnull pointer fields, then we can give a default initializer that zeroes all of its fields. This becomes a requirement when working with partially-imported types like NSDecimal. NSDecimal has bitfields Swift can't see yet, so it's impossible to DI, but the Foundation functions that work with NSDecimal all emit their result by out parameter, and without access to its fields it is impossible to initialize an NSDecimal for use with one of these functions. Implement the initializer using a builtin that gets lowered by IRGen; this is also made necessary by the fact that Swift has only a partial view of the struct, so we can't form a complete zero initializer until we have the definitive type layout from Clang.
Swift SVN r23727
It returns the argument and specifies that the value is not negative.
It has only an effect if the argument is a load or call.
The effect of this builtin is that for the load/call argument a positive range metadata is created in llvm ir.
I also added a public function _assumeNonNegative(x: Int) -> Int in the stdlib.
To be on the save side, I prefixed it with an underscore. But maybe it makes sense to make it available for all users.
Swift SVN r23582
CmpXChg builtins now return (T, Bool) to match the LLVM return value.
Turn the tests back on and check extractvalue / inttoptr instructions.
<rdar://problem/17309776> Update modeling of cmpxchg builtin to handle weak-ness and separate success bit
Swift SVN r23104
Modeling builtins as first-class function values doesn't really make sense because there's no real function value to emit, and modeling them this way complicates passes that work with builtins because they have to invent function types for builtin invocations. It's much more straightforward to have a single instruction that references the builtin by ID, along with the type information for the necessary values, type parameters, and results, so add a new "builtin" instruction that directly represents a builtin invocation. NFC yet.
Swift SVN r22690
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
Eliminate support code for lowering protocol_method instructions, and eliminate ExtraDataKind::Metadata, which is no longer needed now that SIL provides all the necessary type information at the call site.
Swift SVN r22451
- A spot fix in SILGen for reabstracting the result of a downcast, which fixes checked casts to function types.
- Associate the layout information in type metadata records with the most abstract representation of the type. This is the correct thing to do in cases where we need the metadata as a tag for an opaque value--if we store a value in an Any, or pass it as an unconstrained generic parameter, we must maximally reabstract it. This fixes the value semantics of existentials containing trivial metatypes.
- To ensure that we get runtime layout of structs and enums correct when they contain reabstractable types, introduce a "metadata for layout" concept, which doesn't need to describe the canonical metadata for the type, but only needs to describe a type with equivalent layout and value semantics. This is a correctness fix that allows us to correctly lay out generic types containing dependent tuples and functions, and although we don't really take advantage of it here, it's also a potential runtime performance win down the road, because we could potentially produce direct metadata for a primitive type that's layout-equivalent with a runtime-instantiated type. To aid in type safety here, push SILType deeper into IRGen in places where we potentially care about specific representations of types.
- Finally, fix an inconsistency between the runtime and IRGen's concept of what spare bits unmanaged references and thick metatypes have.
Together, these fixes address rdar://problem/16406907, rdar://problem/17822208, rdar://problem/18189508, and likely many other related issues, and also fixes crash suite cases 012 and 024.
Swift SVN r21963
I introduced a function swift_keepAlive2() which has a different signature from
swift_keepAlive() until I can verify that the stdlib is using the new
infrastructure.
The difference in signature is that swift_keepAlive2 takes just a pointer while
swift_keepAlive also takes a metadata value that is not necessary for our
purposes anymore.
Swift SVN r21718
If a type has to be passed or returned resiliently, it
will necessarily be passed indirectly, which is already
represented in SILFunctionType. There is no need to
represent this as a separate channel of information.
NFC. Also fixes a problem where the signature cache
for ExtraData::Block was writing past the end of an
array (but into the storage for an adjacent array
which was fortunately never used).
ExtraData should also disappear as a concept, but we're
still relying on that for existential protocol witnesses.
Swift SVN r21548
it means that the argument should be passed as that
expanded sequence of types.
It turns out that LLVM makes an effort to automatically
break apart such arguments during CC lowering, but (1) it's
friendlier to break them apart ourselves and (2) it's
necessary to break them apart if we want to call inline
functions from the header.
Fixes rdar://17631440
Swift SVN r21420
anything major about IRGen for that type would change,
including the IR type of the value's components.
This generally makes the IR types we use for generic types
more precise, which means we also finally need to properly
remap loadable dependent types when they appear as the
result of a generic function call. This basically only
comes up with class-bounded archetypes, which is why we
haven't run into it a whole lot before.
This all makes a whole lot of things in IRGen involving
generic structs a lot happier and, in particular, fixes
rdar://17986446, the "Unmanaged is horribly busted" bug.
I needed to carve out a big ol' exception for enums, which
apparently cannot be reliably specialized with substituted
types in all cases because of problems with multi-payload
strategies. The exception reinstates the current, incorrect
rule of using a shared implementation whenever the
pattern has a fixed size. This is rooted in a bunch of
deep, known, and tracked problems that I don't have time
to solve.
Swift SVN r21348
Replace the true/maybe state that Builtin.canBeClass was returning by a
tri-state (yes, no, maybe) allowing the optimizer to use the definite no
answer. This removes the need of the sizeof check that we had in
isClassOrObjCExistential. It also removes the need to CSE this function since
in most cases we will be able to instantiate canBeClass to yes or no (vs maybe)
at compile time.
benchmark``````````````,``baserun0``,``optrun2``,``delta,``speedup
ClassArrayGetter```````,``988.00````,``337.00```,``644.00``,````````191.7%
DeltaBlue``````````````,``2429.00```,``1927.00``,``460.00``,````````23.9%
Dictionary`````````````,``1374.00```,``1231.00``,``129.00``,````````10.9%
Havlak`````````````````,``1079.00```,``911.00```,``124.00``,````````13.7%
Rectangles`````````````,``924.00````,``541.00```,``379.00``,````````70.1%
radar://16823238
Swift SVN r21331
This handles things like NSSwapHostLongLongToBig and MKMapRectMake that
are static inline functions that themselves call other static inline
functions.
<rdar://problem/17227237>
Swift SVN r21080
optimization/inlining scheme.
It was actually used while building a release version of stdlib, and
effectively disabled safety checks in debug builds.
Swift SVN r19461
