- Support propagation of let properties values on tuples
- Do not treat initial assignment to a let-property as MemBehavior::None
- Improve comments
- Add more tests.
Swift SVN r28069
Teach LoadStoreOpts to handle "let" variables properly. Such variables should be loaded only once and their loaded values can be reused. This is safe, because once assigned these variables cannot change their value.
Swift SVN r27915
For better consistency with other address-only instruction variants, and to open the door to new exciting existential representations (such as a refcounted boxed representation for ErrorType).
Swift SVN r25902
This is apart of some cleanups of the Projection class.
I also improved the comment at the top of projection to make its usage
clearer.
Swift SVN r23355
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
We ignore casts when generating projection paths for alias analysis. When
comparing two paths, we say no alias when accessing different fields of
the same Decl Context.
Swift SVN r20353
Also stripCasts in findAddressProjectionPathBetweenValues.
We can now move "load of an invariant field" out of the loop even though we
have "store to a different field" in the loop.
Performance:
O3 -----
Phonebook 4367 3866 -11.4724%
Ofast ------
NBody 1623 1292 -20.3943%
EditDistance 3043 2589 -14.9195%
Swift SVN r20327
This commit fixes a bunch of problems I found in TBAA. Some fun
examples:
1. We were not handling protocols correctly.
2. We were not handling enums correctly.
3. We were not handling builtins correctly all the time.
...
And much more.
I also added a fairly exhaustive test.
Additionally I checked the benchmarks and did not see any regressions.
rdar://16651852
Swift SVN r18148
The reason that this is important is that we *ARE* allowing the stdlib
to perform certain types of type punning for efficiency implying we need
to have a type oracle instruction to have safety.
A type oracle instruction is an instruction which implies undefined behavior
unless its operand/result is of a certain type (allowing us to ignore that
possibility).
In a following commit I am going to go over and fix any problems in the
actual TBAA implementation and give all the various checks tests.
rdar://16651852
Swift SVN r18090
This is conditionally compiled out without asserts on.
I am going to use this functionality to test basic-aa and tbaa
separately in different test files.
<rdar://problem/16651852>
Swift SVN r18075
This is due to MayHaveSideEffects encompassing ref count effects and a
myriad of other effects. If/when we separate the two concepts (which is
cleaner IMHO), the flag will no longer be necessary.
Swift SVN r16807
not have their normal memory behavior if the value we are trying to find memory
behavior relative to does not alias their arguments.
Also cond_fail is inert from an AA perspective.
Swift SVN r16806
This is because I need them in ARCAnalysis.cpp and from a modeling
perspective it is no longer just going to be used just in AA since they
are of larger functionality.
Swift SVN r16297
We won't have any types where copying has an effect on the bit pattern (except for blocks, which need special handling anyway), and copy_value having a result makes optimizations more complex, so remove it.
Swift SVN r15640
This will be a signal to ARC optimization, RVO, and other lifetime-affecting optimizations that they should not shorten the lifetime of a value past a certain point. We need this for C pointer bridging. This adds the instruction, but does not add any knowledge of it to the ARC optimizers.
Swift SVN r15601
alloc_ref_dynamic allocates an instance of a class type based on the
value in its metatype operand. Start emitting these instructions for
the allocating constructor of a complete object initializer (not yet
tested) and for the allocating constructor synthesized for an imported
Objective-C init method.
Still missing:
- IRGen still does the same thing as alloc_ref right now. That
change will follow.
- There are devirtualization opportunities when we know the value of
the metatype that would turn an alloc_ref_dynamic into an alloc_ref;
I'm not planning to do this optimization.
Swift SVN r14560
