Fix some comment styles while we are there.
This commit needs a recent version of puzzle/master llvm because I need to make
to const expose the basic block map in the LoopInfo class.
Swift SVN r19630
We're temporarily using @semantics until we have mandatory inlining of branch hints.
We now have @noinline, which helps a lot, but:
- @noinline and "cold/slow" are not the same thing.
- Some functions may need to be inlined into hot paths, but that
doesn't mean we should also inline them into cold paths.
- It is easier to find cold blocks than to look for blocks that
contain calls to @noinline functions. And that doesn't necessarilly
mean the blocks are cold anyway.
Swift SVN r19455
This will be cleaned up for sure at the LLVM level if we do not reach it
at the SIL level implying that this is safe.
<rdar://problem/17419974>
Swift SVN r19262
Previously this was an impossibility so I put in code to check for user error in
case it came up. Now that we have layout compatible reference casts, it makes
sense to add this capability to the optimizer.
Swift SVN r19073
These instructions do a bitcast operation without stack traffic (at the SIL level). unchecked_trivial_bit_cast represents a conversion from a potentially nontrivial type to a trivial type, such as from a class reference to Int. unchecked_ref_bit_cast represents a conversion between types for which retain_value and release_value has equivalent effects when applied on the input or output values.
Swift SVN r19053
Currently in the ARC optimizer, we perform the double release
algorithm. The logic behind the double release algorithm is that given
the following situation:
retain(x)
call(x)
call(x)
release(x)
release(x)
The fact that we have two releases in a row on x implies that before the
first release, we know statically that the reference count of x must be
>= 2 implying we can remove the retain, release pair safely.
This optimization was tempered by the restriction that the two releases
could not have a use in between them.
While thinking about this algorithm, I realized that the key thing about
this optimization is *NOT* that I have two releases in a row. The
interesting part of the optimization is that I know the reference count
of x must be >= 2 before the first release. To ascertain that, we do not
care about having another release, all that we care about is that there
is an operation after the first release that requires x to be
alive. Since x must be alive after the first release, we know that that
release can not be the last release.
This yields a much stronger optimization since it implies that if we see
a release that is post dominated by a second release, we always know
that the first release is known safe. Thus the optimization sequence
looks like the following:
retain(x)
call(x)
call(x)
release(x)
...
use(x)
The current implementation of this algorithm is very simple and just
changes the optimizer by saying that two nested decrements causes the
first decrement to be known safe as long as there is not a retain on the
same pointer in between the two decrements. The reason why this is
important is that if we remove the second release in the ARC optimizer
then that decrement (since it is removed) can not be considered the
local use that allows us to conclude that the first is known safe.
<rdar://problem/17372698> ARC: Implement the stronger release algorithm
Swift SVN r19033
Since the enum instruction is already a "transitive escape instruction",
we can just run the query on the enum's operand and value may be
captured will also make sure that the enum does not escape either.
Swift SVN r18893
This enables us to handle significantly crazier control flow without
needing to worry about control dependency issues relating to different
groups of insertion points potentially not being control dependent which
can cause incorrect behavior in the optimizer.
Swift SVN r18861
Add objc_metatype_to_object and objc_existential_metatype_to_object to convert metatypes to AnyObject, and objc_protocol to get a reference to an @objc protocol descriptor as a Protocol class instance.
Swift SVN r18824
I wish we had the ability to specify a log grouping, so I could log all
of ARC opts or just a specific part of it. Sadly we don't have that now
so I am going to centralize them under the same flag.
Swift SVN r18820
These trap BBs are pattern matched very strictly, i.e. only BBs of the
following form are matched:
bbN:
%_ = builtin_function_ref "int_trap"
apply %_
unreachable
Such BBs can be ignored safely for ARC purposes. This allows us to
handle -O3 code in the ARC optimizer significantly more effectively by
enabling us to handle many more types of check failures.
For instance we can now remove retains, releases in the following code:
bb0:
strong_retain %0
cond_br _, bb1, bb2
bb1:
strong_release %0
...
bb2:
%_ = builtin_function_ref "int_trap"
apply %_
unreachable
rdar://17212610
Swift SVN r18817
put the result in a different place.
WIP: no IRGen support yet.
This will eventually be the required form when casting
to an address-only type; the existing instructions will
have only scalar outputs.
Swift SVN r18780
With this and the previous commit, BST goes to < 10 seconds from not completing
in a reasonable amount of time.
<rdar://problem/17181185>
Swift SVN r18726
Also fixed a small bug related to how we handle arguments. We were not
clearing the state of the argument when we saw a potential decrement of
the argument.
<rdar://problem/17013194>
Swift SVN r18706
GlobalARCSequenceDataflow. Add in the code to implement the bottom up
dataflow, but don't wire it up. Pass in the refactored top down dataflow
to the old pairing pass so we still give correct results.
The next step is to change the pairing analysis to use both the bottom
up and top down dataflow passes.
rdar://16965332
Swift SVN r18551
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
