This is primarily intended for testing use, but the general mechanism of
generating headers from Swift ASTs is how we plan to get Swift modules into
Clang. The final implementation will be some kind of Clang plugin that's
invoked when a module can't be loaded. The use of header files keeps us
from having to rev-lock Swift and Clang for as long as possible.
Swift SVN r11970
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
Previously, the CMake-built Xcode projects for LLVM, Clang, and Xcode
would put binaries into bin/Debug, lib/Debug, bin/Release, etc., which
differed from the makefile build's Debug/bin, Debug/lib, Release/bin,
etc. We installed a few weird-looking symlinks to paper over the
differences.
Mainline LLVM and Clang recently changed to use the makefile layout,
breaking the build of Xcode projects for Swift. Do the same for
Swift's build.
Swift SVN r11819
copy_addr, destroy_addr into their constituant parts without performing any
chopping to unblock Nadav.
The plan is to use type lowering to chop these up and then rewrite afterwards.
But for now I want to unblock Nadav.
Swift SVN r11728
This is a very initial version mostly to get machinery in place before we start
considering more interesting things.
Specifically we do not:
1. Inline functions with any substitutions.
2. Inline functions that are not thin.
3. Inline functions in any recursive manner (i.e. we just follow the call tree
and inline until we run out of cost).
4. Remove functions that we have completely inlined as a good citizen should.
Additionally the cost model is purposely simplistic and assumes that every SIL
instruction is one to one with an LLVM instruction (when many do not become any
LLVM instruction and others become 2). The idea is simply to put a cost on the
total increase in code size we allow due to inlining in a specific function.
Thus we just continually inline until we run out our inlining budget.
Even with the current limitations we inline 1248 apply inst in the stdlib when
setting a cost threshold of 225.
Swift SVN r11596
MainInputFilename and OutputFilename are pulled from the FrontendOptions, while Triple is parsed directly from the ArgList.
Eventually, MainInputFilename and OutputFilename should likely be removed from IRGenOptions, in favor of the values in FrontendOptions, while Triple will be in a separate TargetOptions class.
Swift SVN r11455
Moved the responsibility for storing LinkLibraries from CompilerInvocation to the invocation’s IRGenOpts.
Moved the handling of -l and -framework into ParseIRGenArgs.
Swift SVN r11450
The integrated frontend now supports:
- Parse
- DumpParse
- DumpAST
- PrintAST
- EmitSILGen
- EmitSIL
- EmitIR
- EmitBC
- EmitAssembly
- EmitObject
Moved the code for compiling into a separate performCompile() function in frontend_main.cpp, to facilitate using early returns while still supporting the diagnostic verifier.
Added some error output for the REPL, Immediate, and EmitModuleOnly actions, as the integrated frontend does not yet support these actions.
Swift SVN r11387
Added a new Passes.cpp file to swiftSILPasses, which contains the general SIL pass-related functions.
Moved runSILDiagnosticPasses and runSILOptimizationPasses from tools/swift/Helpers.cpp to lib/SILPasses/Passes.cpp so that the functions can be shared by swift and swift_driver.
Swift SVN r11382
This gives us as a lot of brevity and simplicity. I plan on adding a trivial
remove globals pass to sil-extract to clean these up.
The mechanism that I am using to do this is:
1. Split the entry basic block at its entrance, insert an unreachable terminator.
2. Use DCE to remove all of the original basic blocks. Thus the function will
only consist of 1 BB whose only instruction is a terminator.
3. Go through and clear the functions basic block list.
The key thing about this approach is that it leaves all of the heavy lifting to
DCE.
Swift SVN r11347
This utility is similar to llvm-extract, a tool in LLVM that makes it simpler to
reduce test case by stripping out any global which matches a criteria. Currently
we only deal with functions and the only criteria is an exact name match.
Swift SVN r11343
Actual execution of Jobs is still performed under-the-covers by JobList::run(), but this abstraction will allow the Compilation to execute Jobs in parallel.
Swift SVN r11334
Added PrintHelp and PrintHelpHidden to FrontendOptions.
Marked both -help and --help-hidden with the FrontendOption flag.
Updated ParseFrontendArgs to parse -help and --help-hidden.
Updated frontend_main() so that it prints the help for the frontend options.
Swift SVN r11320
Added a new DiagnosticOptions class to swiftBasic, and added a DiagnosticOptions member to CompilerInvocation.
Added a static ParseDiagnosticArgs function to parse diagnostic-related arguments.
Added -verify to FrontendOptions.td, and added support for parsing -verify in ParseDiagnosticArgs.
Updated frontend_main() to enable and trigger the DiagnosticVerifier when -verify is passed.
Swift SVN r11318
Reapply r11184 with fixes for makefile builds.
Use CodeGenABITypes to determine which return values should be indirect
in @objc methods.
Swift SVN r11226
This works around <rdar://problem/15639860>, which covers properly handling a missing -sdk argument at either the driver or frontend level (or at both levels).
Swift SVN r11153
- Added support for invoking the Swift frontend via "swift_driver -frontend".
- Added frontend_main.cpp, which implements the main entry point for the
integrated frontend. (Currently, this supports compiling an input Swift file
into an object file.)
- Removed lib/Frontend/FrontendOptions.td, and replaced its functionality with
options in include/Swift/Driver/Options.td and a new
include/Swift/Driver/FrontendOptions.td. Options supported by the frontend
are denoted by the FrontendOption flag; options which are not supported by
the driver are denoted by the NoDriverOption flag.
- Updated CompilerInvocation::parseArgs() to use the option table returned from
createDriverOptTable(), including renaming a handful of options. (-triple is
now -target, and -Xclang is now -Xcc.)
Swift SVN r11082
'doIt' is semantically meaningless, and doesn't mention the fact that nothing
has actually been compiled yet (to SIL, to IR, or to machine code).
'performParse' matches the compiler flag -parse, which stops after
type-checking.
No functionality change.
Swift SVN r10951
- Added a couple of new targets:
- libswiftDriver, which contains most of the driver implementation
- swift_driver, which produces the actual executable
- Added centralized version information into libswiftBasic.
- Added a new "Driver Design & Internals" document, which currently describes
the high-level design of the Swift driver.
- Implemented an early version of the functionality of the driver, including
versions of the Parse, Pipeline, Bind, Translate, and Execute driver stages.
Parse, Pipeline, and Bind are largely implemented; Translate and Execute are
early placeholders. (Translate produces "swift_driver --version" and "ld -v"
commands, while Execute performs all subtasks sequentially, rather than in
parallel.)
This is just the starting point for the Swift driver. Tests for the existing
behavior are forthcoming.
Swift SVN r10933
This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
Part of the FileUnit restructuring. A serialized module is now represented as
a TranslationUnit containing a single SerializedASTFile.
As part of this change, the FileUnit interface has been made virtual, rather
than switching on the Kind in every accessor. We think the operations
performed on files are sufficiently high-level that this shouldn't affect us.
A nice side effect of all this is that we now properly model the visibility
of modules imported into source files. Previously, we would always consider
the top-level imports of all files within a target, whether re-exported or
not.
We may still end up wanting to distinguish properties of a complete Swift
module file from a partial AST file, but we can do that within
SerializedModuleLoader.
Swift SVN r10832
The goal of this series of commits is to allow the main module to consist
of both source files and AST files, where the AST files represent files
that were already built and don't need to be rebuilt, or of Swift source
files and imported Clang headers that share a module (because they are in
the same target).
Currently modules are divided into different kinds, and that defines how
decls are looked up, how imports are managed, etc. In order to achieve the
goal above, that polymorphism should be pushed down to the individual units
within a module, so that instead of TranslationUnit, BuiltinModule,
SerializedModule, and ClangModule, we have SourceFile, BuiltinUnit,
SerializedFile, and ClangUnit. (Better names welcome.) At that point we can
hopefully collapse TranslationUnit into Module and make Module non-polymorphic.
This commit makes SourceFile the subclass of an abstract FileUnit, and
makes TranslationUnit hold an array of FileUnits instead of SourceFiles.
To demonstrate that this is actually working, the Builtin module has also
been converted to FileUnit: it is now a TranslationUnit containing a single
BuiltinUnit.
Swift SVN r10830
This patch contains an initial implementation of CSE for SIL ported from LLVM's
earlycse pass. It follows the overall general structure using
ScopedHashTables/DominatorTrees to perform the computation.
Currently it only handles integer literals to ease with the initial review. Once
this gets in I will be spending some time extending the pass to handle other
instructions.
Even with just handling integers this reduces the size of the stdlib in SIL by
~300 lines.
Swift SVN r10794
