Previously, we were not respecting the representation of the existential
metatype and were treating all existential metatypes as if the metatype
was a thick metatype. Instead now we properly grab the instance of the
class from the existential and then query the runtime for the
objc_class. This is done via the new entrypoint
emitHeapMetadataRefForUnknownHeapObject.
I also modified emitHeapMetadataRefForHeapObject to use
emitHeapMetadataRefForUnknownHeapObject instead of
emitLoadOfObjCHeapMetadataRef since the latter does not properly handle
tagged pointers. This bug was found on inspection when Joe and I were
talking about this change.
rdar://18841292
Swift SVN r23308
The code path here is mostly the same as the class cast case--we have to test the ObjC class (if it is a class) against any ObjC protocols, then look up conformances for the native protocols.
Swift SVN r23184
without a valid SILDebugScope. An assertion in IRGenSIL prevents future
optimizations from regressing in this regard.
Introducing SILBuilderWithScope and SILBuilderwithPostprocess to ease the
transition.
This patch is large, but mostly mechanical.
<rdar://problem/18494573> Swift: Debugger is not stopping at the set breakpoint
Swift SVN r22978
This is a type that has ownership of a reference while allowing access to the
spare bits inside the pointer, but which can also safely hold an ObjC tagged pointer
reference (with no spare bits of course). It additionally blesses one
Foundation-coordinated bit with the meaning of "has swift refcounting" in order
to get a faster short-circuit to native refcounting. It supports the following
builtin operations:
- Builtin.castToBridgeObject<T>(ref: T, bits: Builtin.Word) ->
Builtin.BridgeObject
Creates a BridgeObject that contains the bitwise-OR of the bit patterns of
"ref" and "bits". It is the user's responsibility to ensure "bits" doesn't
interfere with the reference identity of the resulting value. In other words,
it is undefined behavior unless:
castReferenceFromBridgeObject(castToBridgeObject(ref, bits)) === ref
This means "bits" must be zero if "ref" is a tagged pointer. If "ref" is a real
object pointer, "bits" must not have any non-spare bits set (unless they're
already set in the pointer value). The native discriminator bit may only be set
if the object is Swift-refcounted.
- Builtin.castReferenceFromBridgeObject<T>(bo: Builtin.BridgeObject) -> T
Extracts the reference from a BridgeObject.
- Builtin.castBitPatternFromBridgeObject(bo: Builtin.BridgeObject) -> Builtin.Word
Presents the bit pattern of a BridgeObject as a Word.
BridgeObject's bits are set up as follows on the various platforms:
i386, armv7:
No ObjC tagged pointers
Swift native refcounting flag bit: 0x0000_0001
Other available spare bits: 0x0000_0002
x86_64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0001
Swift native refcounting flag bit: 0x0000_0000_0000_0002
Other available spare bits: 0x7F00_0000_0000_0004
arm64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0000
Swift native refcounting flag bit: 0x4000_0000_0000_0000
Other available spare bits: 0x3F00_0000_0000_0007
TODO: BridgeObject doesn't present any extra inhabitants. It ought to at least provide null as an extra inhabitant for Optional.
Swift SVN r22880
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
And in IRGen, fix up pointer cast codegen to work with types that explode to single scalars while being stored in named structs. Fixes rdar://problem/18604262
Swift SVN r22671
Simplify binary switches to select_enum instead of enum_is_tag, and make a first attempt at changing passes over to recognize limited forms of select_enum instead of enum_is_tag. There is one case in test/SILPasses/simplify_cfg.sil I wasn't able to figure out, and there are a lot more general passes we could define in terms of select_enum.
Swift SVN r22615
layouts. Introduce new SIL instructions to initialize
and open existential metatype values.
Don't actually, y'know, lift any of the restriction on
existential metatypes; just pointlessly burn extra
memory storing them.
Swift SVN r22592
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
This is off by default and is a modified version of r21996 (reverted in r22001).
Update SILGlobalOpt to remove "once" call from addressor and set the
InitializerF for SILGlboalVariable if legal.
For calls to addressor in non-cold block, we check the addressor to find out
the globalinit_func and the associated SILGlobalVariable. If legal, we set
InitializerF of SILGlobalVariable and remove "once" call from addressor.
The current rules for legality:
1> the addressor contains a single "once" call and it calls globalinit_func.
2> the globalinit_func is called by "once" from a single location.
When we inline the addressor, the globalinit_func will be called by "once"
from multiple locations. After we remove the "once" from the addressor, the
inlined version will mistakely initialize the global variable again.
3> the globalinit_func is trivial as defined by
SILGlobalVariable::canBeStaticInitializer().
Update IRGen to generate constant initializers for global variables with static
initializers (i.e non-null InitializerF).
Joe's suggestion on having the static initializer to return the result instead
of storing it is not implemented in this commit. But we do verify that a static
initializer has a single store to the global variable. The suggestion is tracked
in rdar://18382039.
Implement rdar://16621368, rdar://18169093.
Swift SVN r22083
- 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
This is necessary to be able to properly stash values with nontrivial lowerings, such as metatypes and functions, inside existential containers. Modify SILGen to lower values to the proper abstraction level before storing them in an existential container. Part of the fix for rdar://problem/18189508, though runtime problems still remain when trying to actually dynamicCast out a metatype from an Any container.
Swift SVN r21830
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
We want to be able to work around problems with non-failable
Objective-C initializers actually failing, which can happen when the
API audit data incorrectly marks an initializer as non-failable.
Swift SVN r21711
