storage for arbitrary values.
A buffer doesn't provide any way to identify the type of
value it stores, and so it cannot be copied, moved, or
destroyed independently; thus it's not available as a
first-class type in Swift, which is why I've labelled
it Unsafe. But it does allow an efficient means of
opaquely preserving information between two cooperating
functions. This will be useful for the adjustments I
need to make to materializeForSet to support safe
addressors.
I considered making this a SIL type category instead,
like $@value_buffer T. This is an attractive idea because
it's generally better-typed. The disadvantages are that:
- it would need its own address_to_pointer equivalents and
- alloc_stack doesn't know what type will be stored in
any particular buffer, so there still needs to be
something opaque.
This representation is a bit gross, but it'll do.
Swift SVN r23903
It avoids generation of llvm phi nodes with identical predecessors and differing values.
This change replaces my previous fix of this problem in r23580, where I handled it in IRGen.
There were some discussions about it with the conclusion that it's better to just disallow such cond_br instructions in SIL.
It makes the life easier for some SIL optimizations which can't deal with cond_br with identical destinations.
The original radar is <rdar://problem/18568272> Swift compiler fails with "PHI node has multiple entries for the same basic block with different incoming values!"
Swift SVN r23861
Using the intrinsics is obnoxious because I needed them
to return Builtin.NativeObject?, but there's no reasonable
way to safely generate optional types from Builtins.cpp.
Ugh.
Dave and I also decided that there's no need for
swift_tryPin to allow a null object.
Swift SVN r23824
And fix some bugs with existential conformances, where we were creating a bogus conformance instead of just using null conformances like other code expects.
Swift SVN r23461
Before this patch there was no dependence visible to the optimizer between a
open_existential and the witness_method allowing the optimizer to reorder the
two instruction. The dependence was implicit in the opened archetype but this
is not a concept model by the SIL optimizer.
%2 = open_existential %0 : $*FooProto to $*@opened("...") FooProto
%3 = witness_method $@opened("...") FooProto,
#FooProto.bar!1 : $@cc(...)
%4 = apply %3<...>(%2)
This patch changes the SIL representation such that witness_methods on opened
archetypes take the open_existential (or the producer of the opened existential)
as an operand preventing the optimizer from reordering them.
%2 = open_existential %0 : $*FooProto to $*@opened("...") FooProto
%3 = witness_method $@opened("...") FooProto,
#FooProto.bar!1,
%2 : $*@opened("...") FooProto : $@cc(...)
%4 = apply %3<...>(%2)
rdar://18984526
Swift SVN r23438
Note that I did not change any actual memory behavior. That will come via a
later cleanup phase. Since this is a correctness fix I wanted to only make
things more conservative.
rdar://18568601
Swift SVN r23311
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
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
Update SILGen to create SILGlobalVariable and SILGlobalAddrInst instead of
GlobalAddrInst. When we see a definition for a global variable, we create
the corrsponding SILGlobalVariable definition.
When creating SILGlobalVariable from a global VarDecl, we mangle the global
VarDecl in the same way as we mangle it at IRGen. The SILLinkage is also
set in the same way as we set it at IRGen.
At IRGen, we use the associated VarDecl for SILGlobalVariable if it exists,
to have better debugging information.
We set the initializer for SILGlobalVariable definition only.
We also handle SILGlobalAddrInst in various SILPasses, in the similar way
as we handle GlobalAddrInst.
rdar://15493694
Swift SVN r21887
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 also cleaned up some code in InstructionIdentityComparer. We compare operands
before we hit the comparer, so we don't need to check operand equality there.
Swift SVN r21359
Together these allow you to find the specific cond_br argument that will be
passed to a BB by performing:
CBI->getArgForBB(BB, BBArg->getIndex())
Swift SVN r21326
