Emit a 16-bit constant that tracks the version of the reflection
metadata emitted into binaries. This can be used to cross-check
what is supported by the SwiftRemoteMirror library with the new
version API.
rdar://problem/27251582
We would previously default to ELF. Although the behaviur here is preserved, we
are explicitly mapping the section/segment name based on the output object
format. NFC.
"Sanitizer Coverage" with a new flag ``-sanitize-coverage=``. This
flag is analogous to Clang's ``-fsanitize-coverage=``.
This instrumentation currently requires ASan or TSan to be enabled
because the module pass created by ``createSanitizerCoverageModulePass()``
inserts calls into functions found in compiler-rt's "sanitizer_common".
"sanitizer_common" is not shipped as an individual library but instead
exists in several of the sanitizer runtime libraries so we have to
link with one of them to avoid linking errors.
The rationale between adding this feature is to allow experimentation
with libFuzzer which currently relies on "Sanitizer Coverage"
instrumentation.
Clang IR-generation can fail. When it does this, it destroys the
module. Previously, we were blithely assuming this couldn't happen,
and so we would crash on the deallocated module. Delay the
finalization of the Clang code generator until our own module
finalization, which is a more appropriate place for it anyway,
and then just bail out of the last few steps if Clang fails.
It's like LLVM's MergeFunctions pass, except that it can also merge functions which differ by some constants.
The intention is to merge specialized functions which only differ by metadata lookups. But it can also merge other types of functions.
It gives ~7% code size reducation for the stdlib.
There are still some open TODOs, e.g. to share common code with LLVM's MergeFunctions pass (currently much code is just copied).
Rather than collection nominal type and extension decls and emit
reflection metadata records in one go, we can emit them as they
are encountered and instead collection builtin types referenced
by those at the end.
In order to perform layout, the remote mirrors library needs to know
about the size, alignment and extra inhabitants of builtin types.
Ideally we would emit a reflection info section in libswiftRuntime.o,
but in the meantime just duplicate builtin type metadata for all
builtin types referenced from the current module instead.
In practice only the stdlib and a handful of overlays like the SIMD
overlay use builtin types, and only a few at a time.
Tested manually by running swift-reflection-tool on the standard
library -- I'll add automated tests by using -parse-stdlib to
reference Builtin types in a subsequent patch that adds more layout
logic.
NFC if -enable-reflection-metadata is off.
Currently IRGen stores hashes of the bitcode generated by swift in object files.
This is then used to reduce compile time by not re-codegening if a subsequent
compilation yields a bit code with the same hash.
This is good for users and general compilation, but can result in confusion when
attempting to measure the "real" compile time of the compiler.
By default it is off.
ASan allows to catch and diagnose memory corruption errors, which are possible
when using unsafe pointers.
This patch introduces a new driver/frontend option -sanitize=address to enable
ASan. When option is passed in, the ASan llvm passes will be turned on and
all functions will gain SanitizeAddress llvm attribute.
- Implement emission of type references for nominal type field
reflection, using a small custom encoder resulting in packed
structs, not strings. This will let us embed 7-bit encoded
32-bit relative offsets directly in the structure (not yet
hooked in).
- Use the AST Mangler for encoding type references
Archetypes and internal references were complicating this before, so we
can take the opportunity to reuse this machinery and avoid unique code
and new ABI.
Next up: Tests for reading the reflection sections and converting the
demangle tree into a tree of type references.
Todo: For concrete types, serialize the types for associated types of
their conformances to bootstrap the typeref substitution process.
rdar://problem/15617914
Only re-generate an object file if the llvm IR (after IRGen) changed.
The check is done based on a MD5 hash of the llvm IR which is stored in a special section in the object file.
This reduces compilation time for multi-threaded whole module compilation if only a small number of files are changed.
The incremental compilation also works for compilations with a single output file. In this case it's all-or-nothing.
replace ProtocolConformanceTypeKind with TypeMetadataRecordKind
metadata reference does not need to be indirectable
more efficient check for protocol conformances
remove swift_getMangledTypeName(), not needed yet
kill off Remangle.cpp for non-ObjC builds
cleanup
cleanup
cleanup comments
This times each phase of compilation, so you can see where time is being
spent. This doesn't cover all of compilation, but does get all the major
work being done.
Note that these times are non-overlapping, and should stay that way.
If we add more timers, they should go in a different timer group, so we
don't end up double-counting.
Based on a patch by @cwillmor---thanks, Chris!
Example output, from an -Onone build using a debug compiler:
===-------------------------------------------------------------------------===
Swift compilation
===-------------------------------------------------------------------------===
Total Execution Time: 8.7215 seconds (8.7779 wall clock)
---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---
2.6670 ( 30.8%) 0.0180 ( 25.3%) 2.6850 ( 30.8%) 2.7064 ( 30.8%) Type checking / Semantic analysis
1.9381 ( 22.4%) 0.0034 ( 4.8%) 1.9415 ( 22.3%) 1.9422 ( 22.1%) AST verification
1.0746 ( 12.4%) 0.0089 ( 12.5%) 1.0834 ( 12.4%) 1.0837 ( 12.3%) SILGen
0.8468 ( 9.8%) 0.0171 ( 24.0%) 0.8638 ( 9.9%) 0.8885 ( 10.1%) IRGen
0.6595 ( 7.6%) 0.0142 ( 20.0%) 0.6737 ( 7.7%) 0.6739 ( 7.7%) LLVM output
0.6449 ( 7.5%) 0.0019 ( 2.6%) 0.6468 ( 7.4%) 0.6469 ( 7.4%) SIL verification (pre-optimization)
0.3505 ( 4.1%) 0.0023 ( 3.2%) 0.3528 ( 4.0%) 0.3530 ( 4.0%) SIL optimization
0.2632 ( 3.0%) 0.0005 ( 0.7%) 0.2637 ( 3.0%) 0.2639 ( 3.0%) SIL verification (post-optimization)
0.0718 ( 0.8%) 0.0021 ( 3.0%) 0.0739 ( 0.8%) 0.0804 ( 0.9%) Parsing
0.0618 ( 0.7%) 0.0010 ( 1.4%) 0.0628 ( 0.7%) 0.0628 ( 0.7%) LLVM optimization
0.0484 ( 0.6%) 0.0011 ( 1.5%) 0.0495 ( 0.6%) 0.0495 ( 0.6%) Serialization (swiftmodule)
0.0240 ( 0.3%) 0.0006 ( 0.9%) 0.0246 ( 0.3%) 0.0267 ( 0.3%) Serialization (swiftdoc)
0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) Name binding
8.6505 (100.0%) 0.0710 (100.0%) 8.7215 (100.0%) 8.7779 (100.0%) Total
Assertion failed: (NumUsePointsToFind > 0 && "There must be at least one
releasing instruction for an alloc"), function canPromoteAlloc
Revert "Fix comment for StackPromotion pass in SIL Passes"
Revert "Reapply the StackPromotion commit
0dd045ca04dcc10a33abf57f7e1b08260c4e3de1."
This reverts commit 3f4b1496bd and commit
199cfca13b.
It promotes allocations of native swift objects and array buffers to the stack if it is possible.
The SIL StackPromotion pass is the main part of the optimization. For details see comments there.
Unfortunately we need an additional LLVM pass to handle array buffers, which is not very nice.
I hope that we can get rid of it in future (again: for details see the comments in StackPromotion.cpp)
The optimization gives performance improvements in some benchmarks, mostly related to array literals:
ArrayLiteral: +12%
Combos: +16%
DictionaryLiteral: + 37%
RIPEMD: +10%
StringBuilder: +27%
StringInterpolation: +11%
And last but not least the new benchmark which is dedicated to test stack promotion:
ObjectAllocation: +52%
llvm-swift-opt is a swift only version of opt that will be used to remove
swift's dependency on dynamically injecting passes into opt and to allow for
IRGen's LLVM pipeline to be simulated exactly by reusing the IRGen pass pipeline
building code.
The reason to remove the dynamic code is that it seems that this is code that
will be in flux vis-a-vis the transition to the new pass manager in LLVM, so it
makes sense to make this change now due to the benefit provided by exactly
simulating IRGen.
Swift SVN r32804
The SLPVectorizer vectorizes loads from a packed struct of i2s.
{<i2, i2, i2, i2>}
The problem with that is that LLVM codegens scalar accesses to such a type as
if it where a packed i8 struct.
So when we emit a vector load of <4 x i2> (i.e one byte) and extract any non
zero index element we get garbage. Disable the SLPVectorizer until it is fixed.
rdar://22673382
Swift SVN r32299
The new implementation needs to happen after all source files have been built and before lazy definitions are emitted, but I neglected to insert it in the parallel IRGen path. Fixes rdar://problem/22825770.
Swift SVN r32189
