We have two places in TBAA that uses the class hierarchy to disambiguate types.
This commit removes one of the checks (the one that looked more ad-hock) and
keeps the check in line 540 that uses Type.isSuperclassOf.
Add a cache for calls to typesMayAlias. We never invalidate this cache
because type aliasing relations never change.
The hit rate of this cache is really high.
The AliasAnalysis is unsafe. When we delete instructions we don't have a good
mechanism for invalidating the cache and we don't want instructions to
explicitly invalidate AliasAnalysis after every deletion of an instruction.
Morever, the alias analysis cache _always_ misses. Removing the cache did not
change the build time of the standard library at all.
This fixes type punning issues with unsafeBitCast.
The optimizer is still too aggressive with UnsafePointer. To fix that,
we first need an explicit API for circumventing type safety
(rdar://23406272).
I should be able to fix the following regressions by migrating the
stdlib away from unsafeBitCast to unsafeReferenceCast (~2 weeks).
Slowdowns:
|.Benchmark.................|..Before.|...After.|.Speedup|
|.ArrayInClass..............|...49.00.|...78.00.|.-37.2%.|
|.Sim2DArray................|..471.00.|..549.00.|.-14.2%.|
|.PrimeNum..................|.1876.00.|.1980.00.|..-5.3%.|
Speedups:
|.Benchmark.................|..Before.|...After.|.Speedup|
|.HeapSort..................|.2962.00.|.2663.00.|..11.2%.|
|.StdlibSort................|.2672.00.|.2537.00.|...5.3%.|
This series of commits is reverted because it introduces risk. This type
of change requires design discussion and thorough unit testing.
Revert "Refactor in alias analysis. NFC"
This reverts commit 3390a584b8.
Revert "Update SILArgument alias analysis to make use of the new alias() interface"
This reverts commit 5940fcca78.
Revert "Clean up uneeded SIL in a LIT test"
This reverts commit 81ebb5667f.
Revert "Fix LIT test in basic-aa."
This reverts commit a55340394f.
Revert "Improve comments in alias analysis"
This reverts commit 44ddc5b4df.
Revert "Implement SILArgument and select_enum handling for alias analysis"
This reverts commit 23c257938f.
The cache is using SILValues as keys and such key would contain dangling pointers after the instruction corresponding to a given SILValue is erased.
Therefore, the cache needs to be invalidated between queries. It still makes sense to use the cache during queries, because sometimes queries may be recursive and pretty expensive to compute. It is safe to use caching during the query, because no instructions are being erased while processing it.
The removal of the cache does not seem to affect compile times in a negative way.
This code is self contained was almost 1/2 of all of the code in
AliasAnalysis.cpp. This combined with the fact that we are most likely going to
add more code suggests that it should be refactored out.
Swift SVN r32284
This improves alias analysis results when dealing with function calls.
All clients of the alias analysis (like load-store opts, etc.) will benefit from this.
Reapplying again as rdar://problem/22709812 is resolved.
Swift SVN r32022
This improves alias analysis results when dealing with function calls.
All clients of the alias analysis (like load-store opts, etc.) will benefit from this.
Swift SVN r31960
So far this was done by directly calling PM->getAnalysis() in create*Analysis().
But this required a correct order of analysis definitions in Analysis.def.
Swift SVN r31941
This allows one by editing one place to create an Analysis kind and ensure that
your analysis is properly registered in all of the relevant places for use with
swift/sil-opt.
If we add tools like a sil bugpoint, this will make it easy to add analysis
without having to know about all of these locations.
It also standardizes the create***Analysis API to take a SILModule and a
SILPassManager. All passes take in a SILModule and some take in a
SILPassManager. By standardizing the API and in the cases where SILPassManager
is not used, just making it a dead argument enables metaprogramming.
Swift SVN r31420
- 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
