It can be enabled with the -num-threads <n> option.
Without this option there should be NFC.
When enabled, the LLVM IR is split into multiple modules: one module for each input file.
And for each module an output file is generated. All output files must be specified with -o options:
for each input file in the command line there must be an -o <outputfile> option.
LLVM compilation is performed on each module separately.
This means that the generated code is different than with regular -wmo.
But performance and code size should be approximately the same because important inter-file
optimizations are already done at SIL level (e.g. inlining, specialization).
There is still no support in the driver for this feature.
Swift SVN r25930
As suggested by John. This results in the symbols being coalesced at static
link time into a single strong symbol in a built dylib. Fortunately we don't
care about the contents of these global symbols, so common linkage's
forced zero-initialization is fine. (Hey, C's tentative definitions are
useful for something after all.)
rdar://problem/20072051
Swift SVN r25804
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
Just injecting a new protocol descriptor into an already-running ObjC runtime isn't a good idea, since the runtime might have already canonized the protocol somewhere else, and it won't recognize that classes conform to protocols it doesn't know about.
Swift SVN r23313
When we emit a witness table, build a protocol conformance record for it, and emit the list of all conformance records into a "__swift1_proto" section of the data segment.
Swift SVN r22939
This is a type that has ownership of a reference while allowing access to the
spare bits inside the pointer, but which can also safely hold an ObjC tagged pointer
reference (with no spare bits of course). It additionally blesses one
Foundation-coordinated bit with the meaning of "has swift refcounting" in order
to get a faster short-circuit to native refcounting. It supports the following
builtin operations:
- Builtin.castToBridgeObject<T>(ref: T, bits: Builtin.Word) ->
Builtin.BridgeObject
Creates a BridgeObject that contains the bitwise-OR of the bit patterns of
"ref" and "bits". It is the user's responsibility to ensure "bits" doesn't
interfere with the reference identity of the resulting value. In other words,
it is undefined behavior unless:
castReferenceFromBridgeObject(castToBridgeObject(ref, bits)) === ref
This means "bits" must be zero if "ref" is a tagged pointer. If "ref" is a real
object pointer, "bits" must not have any non-spare bits set (unless they're
already set in the pointer value). The native discriminator bit may only be set
if the object is Swift-refcounted.
- Builtin.castReferenceFromBridgeObject<T>(bo: Builtin.BridgeObject) -> T
Extracts the reference from a BridgeObject.
- Builtin.castBitPatternFromBridgeObject(bo: Builtin.BridgeObject) -> Builtin.Word
Presents the bit pattern of a BridgeObject as a Word.
BridgeObject's bits are set up as follows on the various platforms:
i386, armv7:
No ObjC tagged pointers
Swift native refcounting flag bit: 0x0000_0001
Other available spare bits: 0x0000_0002
x86_64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0001
Swift native refcounting flag bit: 0x0000_0000_0000_0002
Other available spare bits: 0x7F00_0000_0000_0004
arm64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0000
Swift native refcounting flag bit: 0x4000_0000_0000_0000
Other available spare bits: 0x3F00_0000_0000_0007
TODO: BridgeObject doesn't present any extra inhabitants. It ought to at least provide null as an extra inhabitant for Optional.
Swift SVN r22880
instances of Swift subclasses of ObjC classes.
We were already doing this in the runtime. This patch
unhides the runtime's mask word (swift_isaMask) and makes
IR-gen take advantage of it when it can.
Swift SVN r21592
This allows IRGen to complain about types it doesn't know how to lower yet, while still recovering well enough not to take the compiler down with it. This reduces the common "unimplemented enum layout" error to be a mere error instead of a compiler crash.
Swift SVN r20773
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
...so that at least one copy stays around in the final binary. We need this
for /both/ the anchor symbol and the symbol that references it, because
otherwise the /reference/ could get stripped out as unused.
<rdar://problem/16829587>
Swift SVN r17814
When a module built with -autolink-force-load is imported, add a reference
to a special symbol in the corresponding library so that ld is forced to
link it.
This means the library will be linked into the final binary even if no other
symbols are used (which happens for some of our overlays that just add
category methods to Objective-C classes).
Second part of <rdar://problem/16829587>
Swift SVN r17751
This option puts a special symbol into the generated object files that other
object files can reference to force the library to be loaded.
The next commit will modify the way we serialize autolinking information so
that importers of this module will always emit a reference to this symbol.
This means the library will be linked into the final binary even if no other
symbols are used (which happens for some of our overlays that just add
category methods to Objective-C classes).
Part of <rdar://problem/16829587>
Swift SVN r17750
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
when compiling for the simulator.
The simulator doesn't support absolute symbols correctly,
and the ObjC runtime's workaround doesn't visit generic class
patterns.
Swift SVN r12896
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
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
Derive the appropriate ExtraData for a SILFunctionType from its thinness and calling convention. Consider @!thin @cc(witness_method) as having ExtraData::Metatype. This should eliminate all of the unspoken gentleperson's agreements that let thin and witness functions survive IRGen currently when we can turn on SIL witness tables.
Swift SVN r11446
Reapply r11184 with fixes for makefile builds.
Use CodeGenABITypes to determine which return values should be indirect
in @objc methods.
Swift SVN r11226
When we need a reference to protocol or protocol composition type metadata, ask for it through the runtime, instead of referencing statically-emitted protocol metadata.
Swift SVN r9871
Produce protocol descriptors when we see a protocol definition in the current module. If the protocol is @objc, go through the existing path for generating full Protocol* metadata for objc objects; otherwise, emit our layout-compatible but strong-external-linkage Swift protocol descriptor record.
Swift SVN r9867