A function may be eliminated as dead code after initial builtin lowering
occurs. When this happens, an entry in the profile symbol table for the
function is not guaranteed. Its coverage record should be dropped.
rdar://42564768
The compiler shouldn't emit coverage mappings for functions which don't
contain profiling instrumentation. However, due to bugs in the profiling
code, this sometimes happens. In this case, it's better to defensively
drop just the malformed coverage mappings instead of allowing corrupted
profiles to be created.
This patch moves the ownership of profiling state from SILGenProfiling
to SILFunction, where it always belonged. Similarly, it moves ownership
of the profile reader from SILGenModule to SILModule.
The refactor sets us up to fix a few outstanding code coverage bugs and
does away with sad hacks like ProfilerRAII. It also allows us to locally
guarantee that a profile counter increment actually corresponds to the
SILFunction at hand.
That local guarantee causes a bugfix to accidentally fall out of this
refactor: we now set up the profiling state for delayed functions
correctly. Previously, we would set up a ProfilerRAII for the delayed
function, but its counter increment would never be emitted :(. This fix
constitutes the only functional change in this patch -- the rest is NFC.
As a follow-up, I plan on removing some dead code in the profiling
logic and fixing a few naming inconsistencies. I've left that for later
to keep this patch simple.
This patch moves the ownership of profiling state from SILGenProfiling
to SILFunction, where it always belonged. Similarly, it moves ownership
of the profile reader from SILGenModule to SILModule.
The refactor sets us up to fix a few outstanding code coverage bugs and
does away with sad hacks like ProfilerRAII. It also allows us to locally
guarantee that a profile counter increment actually corresponds to the
SILFunction at hand.
That local guarantee causes a bugfix to accidentally fall out of this
refactor: we now set up the profiling state for delayed functions
correctly. Previously, we would set up a ProfilerRAII for the delayed
function, but its counter increment would never be emitted :(. This fix
constitutes the only functional change in this patch -- the rest is NFC.
As a follow-up, I plan on removing some dead code in the profiling
logic and fixing a few naming inconsistencies. I've left that for later
to keep this patch simple.
While invoking the instrprof_increment intrinsic, we used to pass the
profile name variable by using a GEP instruction to get to the string
constant. That prevented llvm from uniquing the names. Use a constexpr
GEP to fix the issue.
Passing {FileID} into the CoverageMappingWriter constructor causes UB.
The ArrayRef constructed from the initializer list becomes invalid once
the constructor returns, because the lifetime of the initializer list
expires. Use an alternate ArrayRef constructor which outlives the
CoverageMappingWriter instance.
This commit also re-reenables coverage_smoke.swift.
rdar://problem/29591622
Instead, pass name pointers to InstrProfiling::lowerCoverageData() using
the new API (via getCoverageUnusedNamesVarName). This ensures that we
don't emit an uncompressed *and* a compressed version of all function
names into the module, fixing rdar://problem/25493310.
Fix a crash in emitBuiltinCall() which occurs because we drop function
linkage information when creating SILCoverageMaps.
This re-applies 45c7e4e86 with the MachO-specific checks in the test
case removed.
Update our usage of llvm's coverage API and fix the way we lower
instrprof_increment intrinsics.
This keeps us up-to-date with llvm/stable and makes instrumented IR
easier to read.
Changes to the coverage mapping API in upstream llvm have caused merge
conflicts and breakage in swift. This commit phases in bits of the new
API in a way that can be safely cherry-picked to swift-{2.2,3.0}-branch.
This commit is NFC for master-next and swift-2.2-branch, but constitutes
an actual bugfix for 3.0. That's because 3.0 is paired with a version of
llvm that takes advantage of the new coverage API to reduce the size of
instrumented binaries.
This effectively closes Swift PR-1053.
(cherry picked from commit a079d313fe)
We emit an extra byte in the name field of function mapping records. The
extra null byte confuses llvm InstrProfReader, resulting in a loss of
coverage information.
We need execution tests to prevent this sort of issue from arising in
the future. Before that can happen, swift needs to start maintaining its
own branches of compiler-rt (this is SR-601).
Swift PR 1051, rdar://problem/24267336
(cherry picked from commit a476c2828a)
If multiple swift files are compiled together, then guessing as to the
file when we emit IR obviously doesn't work. Find the filename when we
generate a function's coverage map and propagate it through SIL.
Swift SVN r25436
