The only real change here is that module-wide IR (autolinking and ObjC
runtime flags) have been pushed up from emitTranslationUnit (now
emitSourceFile) to its only caller, performIRGeneration.
Swift SVN r9075
-disable-llvm-optzns in clang tells the frontend to do everything it would
normally do at lets say -O2, except run the actual LLVM IR passes on the
resulting IR. This is useful in the case where one wants to look at the result
of a non gauranteed SIL optimization pass at the IR level without llvm
optimizations applied.
Swift SVN r8594
...instead of just those that are re-exported. This will be used for
autolinking (and probably few other places).
As part of this, we get two name changes:
(1) Module::getReexportedModules -> getImportedModules
(2) TranslationUnit::getImportedModules -> getImports
The latter doesn't just get modules-plus-access-paths; it also includes
whether or not the import is re-exported. Mainly, though, it just didn't
seem like a good idea to overload this name when the two functions aren't
really related.
No tests yet, will come with autolinking.
Swift SVN r7487
proposal.
When compiling with debug info, build a swiftmodule that contains all the
type decls referenced by DWARF and emit it into a special __apple_swiftast
section in the .o file.
Swift SVN r7398
Dynamic forms of these methods will ultimately move to the fully general TypeInfo class, but for now I'm focusing on getting fixed-layout unions working. Set up methods on FixedTypeInfo for getting the fixed count of extra inhabitants and the spare bit mask for a type. Have the default implementation of extra inhabitants count use the spare bits. For now, only actually set spare bits for types with IR-level single scalar non-power-of-two integer representation (e.g., i1, or i21).
Swift SVN r7289
gen pass has had it disabled for some time, so snip the last few uses
in the REPL and zap it.
Goodbye old friend, you were a very useful stopgap.
Swift SVN r6885
fix the build. This isn't a proper fix (we should start putting out new attributes
on llvm::Function's, but getting the build working again seems important.
Swift SVN r6584
This unfortunately duplicates the hack of directly referencing the Clang
module loader if a cross-reference points to the current module; ideally
we'd have some kind of module chain, but I'd settle for a refactoring of
the code to share with NameBinding.
Additionally, Clang nodes are not actually validated to be from the right
module, which could be problematic for extensions or any case of actual
name collision.
Swift SVN r6519
redefinition (or linkage type) bug that causes two tests to fail. I filed
rdar://13670581 to track this and am plowing forward, since they seem minor.
Swift SVN r4761
LLVM recently changed to autodetect host features by default. Change our default to use the "generic" CPU so that we emit binaries to a portable baseline (until some time in the future when we have proper -mtune and -mattr flags).
Swift SVN r4310
Implement lowering of SIL ClosureInsts by packing the partial arguments into a heap allocation and emitting a thunk to unpack them and apply the closure function, similar to curried entry points. The test doesn't work quite yet because nested FuncDecls don't get visited anymore. I need to replace my hacked SIL path with a proper walk of the SIL module to generate functions and the AST to generate types.
Swift SVN r3817
Add a path through IRGenModule to optionally codegen FuncDecls using their corresponding SIL Functions when constructed with a SILModule. Jury-rig an IRGenSILFunction subclass of IRGenFunction that does the bare minimum necessary to compile "hello world" from SIL. There are some impedance mismatches between irgen and SIL that need to be smoothed out, particularly the AST-dependent way irgen currently handles function calls. Nonetheless, `swift -sil-i hello.swift` works!
Swift SVN r3759
It doesn't do anything but crash yet. Also add an entry point fo SILGen to Subsystems so that it can be invoked without dependency on SIL or SILGen.
Swift SVN r3738
There is no protection whatsoever if the Clang-to-Swift type
conversion produces something that Swift doesn't lower in an
ABI-compatible way. That will be dealt with later.
Swift SVN r3249
This makes the two phases independently testable, but is also the
right thing to do: previously we'd form swift_retain early enough
that inlining would inline them from previously optimized callees
into callers, and this would block some mid-level optimizations
from doing nice things (because swift_retain isn't no-escape).
It's a small thing, but doing this allows us to eliminate a few
more "and x, 9223372036854775807"'s from the stdlib. We also
end up doing a lot less optimizations because we do them early
instead of only having the optimizations exposed after inlining
deeply.
Swift SVN r2114
