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
Currently only inline functions referenced from Swift source files, or
from the REPL, will get IR generated for them. Inline functions
referenced by other inline functions will require additional effort to
generate properly.
With this change we use the clang::CodeGenerator-created llvm::Module
for all IR generation in Swift. This is perhaps undesirable, but
unavoidable given the interface the public Clang APIs expose, which do
not allow for building a ModuleBuilder that borrows an existing
llvm::Module.
Also unfortunate is the hack to generate a UsedAttr for each imported
inline function, but the public Clang APIs do not provide a way to only
emit deferred decls without emitting other things (e.g. module flags
that conflict with what the Swift IRGen emits). Note that we do not do
IRGen for every inline function in the module - only the ones that the
importer pulls in, which appears to be only those transitively
referenced from Swift code.
Swift SVN r13134
Previously it would create a new module if one was not passed in. There
are no uses where we do not or cannot provide a module, so it seems
reasonable to make the interface consistently require a module.
Swift SVN r13016
Adjusted how this option is handled: it is now set in IRGenOptions. If set,
this prevents the relevant passes from being added at all, instead of making
them no-ops.
Swift SVN r13005
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
We're still synthesizing external definitions too eagerly, and things
getting pulled in only through submodules aren't getting properly autolinked.
(That is, AppKit imports <QuartzCore/CIImage.h> but doesn't think that
QuartzCore is visible, because it isn't.)
The first right answer is to detect that a part of QuartzCore is visible even
though the whole thing isn't. The second right answer is to properly handle
Clang submodules as real modules---there are a lot of rough edges there.
<rdar://problem/13140302>. The third right answer is that we shouldn't even
emit references to these symbols until the /user/ needs them.
And what I'm doing now is just to attempt to link to every module that we've
synthesized thunks for.
<rdar://problem/15754311>
Swift SVN r12031
Although Cocoa.framework re-exports AppKit, Foundation, and CoreData, an
arbitrary library does not re-export most of its imports. Normally this
would be fine, but the Clang importer can pull in types too eagerly and
then generate thunks and wrappers for things we don't care about. At least
for now, return to the behavior of autolinking /anything/ that gets visibly
imported.
<rdar://problem/15705923>
Swift SVN r11844
