This adds the -profile-generate flag, which enables LLVM's
instrumentation based profiling. It implements the instrumentation
for basic control flow, such as if statements, loops, and closures.
Swift SVN r25155
This pass removes almost half of the value witness functions in the dylib,
about 8% of the code in the dylib, and about 4% of the total dylib size.
Swift SVN r24920
We've had a rash of bugs due to inconsistencies between how IRGen and the runtime think types are laid out. Add a '-verify-type-layout' mode to the frontend that causes IRGen to emit a bunch of code that compares its static assumptions against what the runtime value witness does.
Swift SVN r24918
This has been long in coming. We always had it in IRGenOpts (in string form).
We had the version number in LangOpts for availability purposes. We had to
pass IRGenOpts to the ClangImporter to actually create the right target.
Some of our semantic checks tested the current OS by looking at the "os"
target configuration! And we're about to need to serialize the target for
debugging purposes.
Swift SVN r24468
The underlying problem is that e.g. even if a method is private but its class is public, the method can be referenced from another module - from the vtable of a derived class.
So far we handled this by setting the SILLinkage of such methods according to the visibility of the class. But this prevented dead method elimination.
Now I set the SILLinkage according to the visibility of the method. This enables dead method elimination, but it requires the following:
1) Still set the linkage in llvm so that it can be referenced from outside.
2) If the method is dead and eliminated, create a stub for it (which calls swift_reportMissingMethod).
Swift SVN r23889
Use the CodeGenOptions the Clang frontend determined for the compiler instance instead of starting from scratch, so that we pick up important settings like '-mstackrealign'. Fixes the GLKit test on iOS. rdar://problem/19180367
Swift SVN r23792
Factor out the code that sets up llvm::TargetOptions and SubtargetFeatures via Clang, and reuse it in immediate mode to properly set up the ExecutionEngine to be consistent with the environment we emitted code for. This makes it so that we can use code that lowers to, for instance, SSE3 intrinsics, in particular stuff like GLKit code imported from Clang.
Swift SVN r23646
Previously we hardcoded a few important default CPUs, ABIs, and features into
Swift's driver, duplicating work in Clang. Now that we're using Clang's
driver to create the Clang "sub-compiler", we can delegate this work to Clang.
As part of this, I've dropped the options for -target-abi (which was a
frontend-only option anyway) and -target-feature (which was a hidden driver
option and is a frontend-only option in /Clang/). We can revisit this later
if it becomes interesting. I left in -target-cpu, which is now mapped
directly to Clang's -mcpu=.
Swift SVN r22449
ABI version to '2'.
This patch shows that we need to consolidate where we encode
version information in our CMake build; that's for a later patch.
Implements rdar://problem/18238390.
Swift SVN r21850
OptimizeARC does not only contain an optimize arc pass: the library also
includes aa. What this really is a repository of the extra passes and
infrastructure that we inject into LLVM. Thus LLVMPasses is a more descriptive
name. It also matches SILPasses.
I also taught lit how to use the new llvm-opt driver for running swift llvm
passes through opt without having to remember how to setup the dynamic swift
llvm pass dylib. You can use this in lit tests by using the substitution
%llvm-opt.
Swift SVN r21654
classes, UseJIT will also be set, so we don't
need to check.
And there's an important case where we *don't*
need to register classes: testcases, which break
if we do try to register classes, with the
following assertion:
Assertion failed: (registered == c && "objc_readClassPair failed to instantiate the class in-place"), function swift_instantiateObjCClass, file /Volumes/Excelion/swift/lldb-work/llvm/tools/swift/stdlib/runtime/SwiftObject.mm, line 594.
So only register classes if UseJIT is enabled,
and ignore the playground flag.
Swift SVN r20655
We were already effectively doing this everywhere /except/ when building
the standard library (which used -O2), so just use the model we want going
forward.
Swift SVN r20455
Doing so causes the linker to list the framework itself as one of its
dependencies, which confuses tools that depend on the linker's dependency
output.
<rdar://problem/17006845>
Swift SVN r18578
To help with the playground's transition to top level code, hand the -playground frontend flag down to IRGenOptions, so that IRGen knows to emit runtime initializer code for classes and categories into top_level_code rather than an attributed function.
Swift SVN r18479
This current fix will initialize all objective C classes with the objective C runtime when any ObjC classes are defined in expressions
<rdar://problem/16029117>
Swift SVN r18037
which provides the Neon feature. Do all the necessary
plumbing to get this from the driver to the backend.
Also, support -arch arm64, and diagnose bad -arch values
instead of silently ignoring them. It's not clear to me
that we really want to support -arch as an alternative
to -target, but unless we rip it out or establish some
sort of real policy about it, it really ought to do
something approximating the right thing.
It would be nice if we could abstract enough of clang's
driver that we could re-use some of its basic logic about
tool chains and targets instaed of iteratively
rediscovering everything it does that's actually
critically important.
Swift SVN r16447
Finishes the removal of the old "wrapped" module section that was made
unnecessary in r12922/3. Now that we no longer use the old compiler, we
don't need this at all. That also removes the need for SwiftTargetMachine.
No functionality change; this was all dead code.
Swift SVN r14758
The default (F_None) used to mean F_Text, now it is F_Binary, which is arguably
a better default. It only matters on Windows anyway, so just use F_None (to
mean binary mode) everywhere to allow Swift to be compled with older LLVM as
well as current ToT.
Swift SVN r14312
rdar://13013457
'import Cocoa' is still generating a ton of unnecessary
global metadata, which causes some unused VWTs to be built,
but at least we no longer generate tons of useless global
functions. At least, we don't in IR-gen --- we still do
all the SILGen work for them.
Swift SVN r14224
We're mostly not that bad about this right now, but lazy
emission is going to wreak havoc.
Note that SILGen itself doesn't really make very good decisions
about the order in which to emit functions, but step one
towards fixing that is actually respecting it.
Swift SVN r14200
Prior to r13134, the modules being constructed for IRGen always used the
LLVM global context due to <rdar://problem/15283227>, but the interface
should really take this as a parameter rather than baking the behavior
into IRGen.
Swift SVN r13260
