These are distinct statistics which are useful to look at separately.
Example: say you have a template function "foo" with 5 instantiations
and only 3 of them are covered. Then this contributes (1/1) to the total
function coverage and (3/5) to the total instantiation coverage. I.e,
the old "Function Coverage" column has been renamed to "Instantiation
Coverage", and the new "Function Coverage" aggregates information from
the various instantiations of a function.
One benefit of making this switch is that the Line and Region coverage
columns will start making sense. Let's continue the example and assume
that the 5 instantiations of "foo" cover {2, 4, 6, 8, 10} out of 10
lines respectively. The new line coverage for "foo" is (10/10), not
(30/50). The old scenario got confusing because we'd report that there
were more lines in a file than what was actually possible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281875 91177308-0d34-0410-b5e6-96231b3b80d8
This drops some redundant calls to get{UniqueSourceFiles,
CoveredFunctions}. We can figure out the right column widths without
re-doing this expensive work.
This isn't NFC, but I don't want to check in another binary *.covmapping
file with long filenames in it. I tested this locally on a project with
some long filenames (FileCheck).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281873 91177308-0d34-0410-b5e6-96231b3b80d8
In practice, it's way too noisy.
It's also a maintenance burden, since we apparently can't add tests for
it without breaking some Windows setups (see: D22692).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281871 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Previously we reline on inst-combine to remove inlinable invoke instructions. This causes trouble because a few extra optimizations are schedule early that could introduce too much CFG change (e.g. simplifycfg removes too much control flow). This patch handles invoke instruction in-place during sample profile annotation, so that we do not rely on instcombine to remove those invoke instructions.
Reviewers: davidxl, dnovillo
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24409
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281870 91177308-0d34-0410-b5e6-96231b3b80d8
With D24253 we can now use SelectionDAG::SignBitIsZero with vector operations.
This patch uses SelectionDAG::SignBitIsZero to recognise that a zero sign bit means that we can use a sitofp instead of a uitofp (which is not directly support on pre-AVX512 hardware).
While AVX512 does provide support for uitofp, the conversion to sitofp should not cause any regressions.
Differential Revision: https://reviews.llvm.org/D24343
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281852 91177308-0d34-0410-b5e6-96231b3b80d8
It is a trivial change which could make the testcase easier to be reused
for the store splitting in CodeGenPrepare.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281846 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This fixes an issue when files are compiled with -flto=thin
at default -O0. We need to rename anonymous globals before attempting
to write the module summary because all values need names for
the summary. This was happening at -O1 and above, but not before
the early exit when constructing the pipeline for -O0.
Also add an internal -prepare-for-thinlto option to enable this
to be tested via opt.
Fixes PR30419.
Reviewers: mehdi_amini
Subscribers: probinson, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D24701
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281840 91177308-0d34-0410-b5e6-96231b3b80d8
We were trying to avoid using a FrameIndex operand in non-pointer
operands in a convoluted way, and would break because of
using TargetFrameIndex. The TargetFrameIndex should only be used
in the case where it makes sense to fold it as part of the addressing
mode, otherwise it requires materialization like a normal constant.
This wasn't working reliably and failed in the added testcase, hitting
the assert when processing the frame index.
The TargetFrameIndex was coming from trying to produce an AssertZext
limiting the maximum stack size. I'm not sure this was correct to begin
with, because it is apparently possible to have a single workitem
dispatch that requires all 4G of private memory.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281824 91177308-0d34-0410-b5e6-96231b3b80d8
This reduces the number of copies and reg_sequences
when using fp constant vectors. This significantly
reduces the code size in local-stack-alloc-bug.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281822 91177308-0d34-0410-b5e6-96231b3b80d8
The ValueSymbolTable is used to detect name conflict and rename
instructions automatically. This is not needed when the value
names are automatically discarded by the LLVMContext.
No functional change intended, just saving a little bit of memory.
This is a recommit of r281806 after fixing the accessor to return
a pointer instead of a reference and updating all the call-sites.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281813 91177308-0d34-0410-b5e6-96231b3b80d8
