The only interesting bit is that for stdlib/objc to build reliably, its
.o files all need to depend on the generated swiftmodule files for any
of its library dependencies. It looks like cmake treats
target_link_libraries as only implying a dependency between the
resulting libraries, and not the objects. For now, I've achieved this
by making the objects depend on the whole target (which includes
linking), but only the swiftmodule is actually necessary.
Swift SVN r20240
Implements redundant bounds check elimination for basic blocks and along the
dominator tree of loops.
No induction variable based hoisting yet.
O3:
NBody , 473.00 , 122.00 , 294.2%
QuickSort , 477.00 , 310.00 , 53.9%
RC4 , 1022.00 , 736.00 , 38.6%
Walsh , 1781.00 , 1142.00 , 55.5%
No effect on Ofast.
Disabled for now.
Swift SVN r20199
Reapplies r20137 with most comments addressed.
Parses a YAML file (but not the final/full format yet).
Adds an entry to the driver for the apinotes "tool". We want the tool
to be visible to the user so it has to go to the driver.
Very limited testing as of now.
Swift SVN r20173
Parses a YAML file (but not the final/full format yet).
Adds an entry to the driver for the apinotes "tool". We want the tool
to be visible to the user so it has to go to the driver.
Very limited testing as of now.
Swift SVN r20137
We do this so that the swiftmodule file contains all info necessary to
reconstruct the AST for debugging purposes. If the swiftmodule file is copied
into a dSYM bundle, it can (in theory) be used to debug a built app months
later. The header is processed with -frewrite-includes so that it includes
any non-modular content; the user will not have to recreate their project
structure and header maps to reload the AST.
There is some extra complexity here: a target with a bridging header
(such as a unit test target) may depend on another target with a bridging
header (such as an app target). This is a rare case, but one we'd like to
still keep working. However, if both bridging headers import some common.h,
we have a problem, because -frewrite-includes will lose the once-ness
of #import. Therefore, we /also/ store the path, size, and mtime of a
bridging header in the swiftmodule, and prefer to use a regular parse from
the original file if it can be located and hasn't been changed.
<rdar://problem/17688408>
Swift SVN r20128
This is not run by default unless one passes in the flag -Xllvm -enable-global-load-store-opts.
Also in order to make sure in the face of multi-bbs dead store elimination is
still correct, we use the post order dominator tree to determine if the dead
store is post dominated by the store that is causing it to be dead.
With this pass enabled, we see a 3.5% decrease in overall time in the precommit
bench and the following tests increase in speed by > 5%:
2Sum: 8.9%
Rectangles: 7.35%
Ackermann: 6.43%
StringBuilder: 6.16%
EditDistance: 5.71%
StringWalk: 5.58%
That means that 30% of our benchmarks increased in speed by > 5%. Many of the
other benchmarks increased in speed significantly but not as drmatically.
The only benchmark that regressed is SmallPt which I am looking into.
rdar://17680758
Swift SVN r20009
We don't need module names for properties and methods, since they're
effectively unique within a class. Moreover, use all of the
distinguishing characteristics as the key for the stored
representation in the side car writer. No visible functionality
change; this is staging.
Swift SVN r20008
Extend swift-ide-test with a mode that generates a side car file from
the built-in KnownObjCMethods.def, which gives us an easy way to
source the information we want in the side car. This is a temporary
measure until we have a textual format for side car data and the
ability to translate that into the binary format.
Swift SVN r19994
This ensures that if we have a bunch of passes in a row which modify the CFG, we
do not continually rebuild the post order, while at the same time preserving the
property of multiple passes which do not touch the CFG sharing the same post
order, reverse post order rather than recomputing them.
rdar://17654239
Swift SVN r19913
The induction variable analysis derives from the SCC visitor CRTP-style
and uses it to drive analysis to find the IVs of a function.
The current definition of induction variable is very weak, but enough to
use for very basic bounds-check elimination.
This is not quite ready for real use. There is an assert that I've
commented out that is firing but should not be, and that will require
some more investigation.
Swift SVN r19845
The options themselves are now in swift::options (from swift::driver::options).
The soon-to-be-renamed createDriverOptTable() is now directly in the swift namespace.
Swift SVN r19825
This allows swiftFrontend to drop its dependency on swiftDriver, and could
someday allow us to move the integrated frontend's option parsing out of
swiftFrontend (which would allow other tools which use swiftFrontend to
exclude the option table entirely).
Swift SVN r19824
The upshot of this is that internal decls in an app target will be in the
generated header but internal decls in a framework target will not. This
is important since the generated header is part of a framework's public
interface. Users always have the option to add members via category to an
internal framework type they need to use from Objective-C, or to write the
@interface themselves if the entire type is missing. Only internal protocols
are left out by this.
The presence of the bridging header isn't a /perfect/ way to decide this,
but it's close enough. In an app target without a bridging header, it's
unlikely that there will be ObjC sources depending on the generated header.
Swift SVN r19763
The main purpose of this pass is to hoist invariant loads out of loops. This
will enable llvm to vectorize loops with array accesses in Ofast once we hoist
the makeUnique functions.
Disabled for now.
rdar://17142604
Swift SVN r19713
In the frontend, only arguments after '--' will be passed as arguments
to the new process. Also, add the input filename as argv[0], to follow
the usual conventions.
Still to come is fixing swift -i from the driver.
Swift SVN r19690
