Revert "[Coverage] Store compilation dir separately in coverage mapping"

This reverts commit 97ec8fa5bb07e3f5bf25ddcb216b545cd3d03b65 since
the test is failing on some bots.

[Coverage] Store compilation dir separately in coverage mapping

We currently always store absolute filenames in coverage mapping. This
is problematic for several reasons. It poses a problem for dis

[Coverage] Store compilation dir separately in coverage mapping

We currently always store absolute filenames in coverage mapping. This
is problematic for several reasons. It poses a problem for distributed
compilation as source location might vary across machines. We are also
duplicating the path prefix potentially wasting space.

This change modifies how we store filenames in coverage mapping. Rather
than absolute paths, it stores the compilation directory and file paths
as given to the compiler, either relative or absolute. Later when
reading the coverage mapping information, we recombine relative paths
with the working directory. This approach is similar to handling
ofDW_AT_comp_dir in DWARF.

Finally, we also provide a new option, -fprofile-compilation-dir akin
to -fdebug-compilation-dir which can be used to manually override the
compilation directory which is useful in distributed compilation cases.

Differential Revision: https://reviews.llvm.org/D95753

show more ...

[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage

This is an enhancement to LLVM Source-Based Code Coverage in clang to track how
many times individual branch-generating

[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage

This is an enhancement to LLVM Source-Based Code Coverage in clang to track how
many times individual branch-generating conditions are taken (evaluate to TRUE)
and not taken (evaluate to FALSE). Individual conditions may comprise larger
boolean expressions using boolean logical operators. This functionality is
very similar to what is supported by GCOV except that it is very closely
anchored to the ASTs.

Differential Revision: https://reviews.llvm.org/D84467

show more ...

[llvm-cov] Warn when -arch spec is missing/invalid for universal binary (reland)

llvm-cov reports a poor error message when the -arch specifier is
missing or invalid, and a binary has multiple slice

[llvm-cov] Warn when -arch spec is missing/invalid for universal binary (reland)

llvm-cov reports a poor error message when the -arch specifier is
missing or invalid, and a binary has multiple slices. Make the error
message more specific.

(This version of the patch avoids using llvm::none_of -- the way I used
the utility caused compile errors on many bots, possibly because the
wrong overload of `none_of` was selected.)

rdar://40312677

show more ...

Revert "[llvm-cov] Warn when -arch spec is missing/invalid for universal binary"

This reverts commit b81d4bfb44c14575130bb06c047728b69c3213aa.

It's causing some bots to fail to build due to: "error

Revert "[llvm-cov] Warn when -arch spec is missing/invalid for universal binary"

This reverts commit b81d4bfb44c14575130bb06c047728b69c3213aa.

It's causing some bots to fail to build due to: "error: no matching
function for call to ‘__iterator_category".

show more ...

[llvm-cov] Warn when -arch spec is missing/invalid for universal binary

llvm-cov reports a poor error message when the -arch specifier is
missing or invalid, and a binary has multiple slices. Make t

[llvm-cov] Warn when -arch spec is missing/invalid for universal binary

llvm-cov reports a poor error message when the -arch specifier is
missing or invalid, and a binary has multiple slices. Make the error
message more specific.

rdar://40312677

show more ...

[Coverage] Collect all function records in an object (D69471 followup)

After the format change from D69471, there can be more than one section
in an object that contains coverage function records. L

[Coverage] Collect all function records in an object (D69471 followup)

After the format change from D69471, there can be more than one section
in an object that contains coverage function records. Look up each of
these sections and concatenate all the records together.

This re-enables the instrprof-merging.cpp test, which previously was
failing on OSes which use comdats.

Thanks to Jeremy Morse, who very kindly provided object files from the
bot I broke to help me debug.

show more ...

Reland: [Coverage] Revise format to reduce binary size

Try again with an up-to-date version of D69471 (99317124 was a stale
revision).

---

Revise the coverage mapping format to reduce binary size

Reland: [Coverage] Revise format to reduce binary size

Try again with an up-to-date version of D69471 (99317124 was a stale
revision).

---

Revise the coverage mapping format to reduce binary size by:

1. Naming function records and marking them `linkonce_odr`, and
2. Compressing filenames.

This shrinks the size of llc's coverage segment by 82% (334MB -> 62MB)
and speeds up end-to-end single-threaded report generation by 10%. For
reference the compressed name data in llc is 81MB (__llvm_prf_names).

Rationale for changes to the format:

- With the current format, most coverage function records are discarded.
E.g., more than 97% of the records in llc are *duplicate* placeholders
for functions visible-but-not-used in TUs. Placeholders *are* used to
show under-covered functions, but duplicate placeholders waste space.

- We reached general consensus about giving (1) a try at the 2017 code
coverage BoF [1]. The thinking was that using `linkonce_odr` to merge
duplicates is simpler than alternatives like teaching build systems
about a coverage-aware database/module/etc on the side.

- Revising the format is expensive due to the backwards compatibility
requirement, so we might as well compress filenames while we're at it.
This shrinks the encoded filenames in llc by 86% (12MB -> 1.6MB).

See CoverageMappingFormat.rst for the details on what exactly has
changed.

Fixes PR34533 [2], hopefully.

[1] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118428.html
[2] https://bugs.llvm.org/show_bug.cgi?id=34533

Differential Revision: https://reviews.llvm.org/D69471

show more ...

Revert "[Coverage] Revise format to reduce binary size"

This reverts commit 99317124e1c772e9a9de41a0cd56e1db049b4ea4. This is
still busted on Windows:

http://lab.llvm.org:8011/builders/lld-x86_64-w

Revert "[Coverage] Revise format to reduce binary size"

This reverts commit 99317124e1c772e9a9de41a0cd56e1db049b4ea4. This is
still busted on Windows:

http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/40873

The llvm-cov tests report 'error: Could not load coverage information'.

show more ...

[Coverage] Revise format to reduce binary size

Revise the coverage mapping format to reduce binary size by:

1. Naming function records and marking them `linkonce_odr`, and
2. Compressing filenames.

[Coverage] Revise format to reduce binary size

Revise the coverage mapping format to reduce binary size by:

1. Naming function records and marking them `linkonce_odr`, and
2. Compressing filenames.

This shrinks the size of llc's coverage segment by 82% (334MB -> 62MB)
and speeds up end-to-end single-threaded report generation by 10%. For
reference the compressed name data in llc is 81MB (__llvm_prf_names).

Rationale for changes to the format:

- With the current format, most coverage function records are discarded.
E.g., more than 97% of the records in llc are *duplicate* placeholders
for functions visible-but-not-used in TUs. Placeholders *are* used to
show under-covered functions, but duplicate placeholders waste space.

- We reached general consensus about giving (1) a try at the 2017 code
coverage BoF [1]. The thinking was that using `linkonce_odr` to merge
duplicates is simpler than alternatives like teaching build systems
about a coverage-aware database/module/etc on the side.

- Revising the format is expensive due to the backwards compatibility
requirement, so we might as well compress filenames while we're at it.
This shrinks the encoded filenames in llc by 86% (12MB -> 1.6MB).

See CoverageMappingFormat.rst for the details on what exactly has
changed.

Fixes PR34533 [2], hopefully.

[1] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118428.html
[2] https://bugs.llvm.org/show_bug.cgi?id=34533

Differential Revision: https://reviews.llvm.org/D69471

show more ...

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3b

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.

show more ...

Remove redundant "std::move"s in return statements

Revert "[Coverage] Revise format to reduce binary size"

This reverts commit e18531595bba495946aa52c0a16b9f9238cff8bc.

On Windows, there is an error:

http://lab.llvm.org:8011/builders/sanitizer-win

Revert "[Coverage] Revise format to reduce binary size"

This reverts commit e18531595bba495946aa52c0a16b9f9238cff8bc.

On Windows, there is an error:

http://lab.llvm.org:8011/builders/sanitizer-windows/builds/54963/steps/stage%201%20check/logs/stdio

error: C:\b\slave\sanitizer-windows\build\stage1\projects\compiler-rt\test\profile\Profile-x86_64\Output\instrprof-merging.cpp.tmp.v1.o: Failed to load coverage: Malformed coverage data

show more ...

[Coverage] Revise format to reduce binary size

Revise the coverage mapping format to reduce binary size by:

1. Naming function records and marking them `linkonce_odr`, and
2. Compressing filenames.

[Coverage] Revise format to reduce binary size

Revise the coverage mapping format to reduce binary size by:

1. Naming function records and marking them `linkonce_odr`, and
2. Compressing filenames.

This shrinks the size of llc's coverage segment by 82% (334MB -> 62MB)
and speeds up end-to-end single-threaded report generation by 10%. For
reference the compressed name data in llc is 81MB (__llvm_prf_names).

Rationale for changes to the format:

- With the current format, most coverage function records are discarded.
E.g., more than 97% of the records in llc are *duplicate* placeholders
for functions visible-but-not-used in TUs. Placeholders *are* used to
show under-covered functions, but duplicate placeholders waste space.

- We reached general consensus about giving (1) a try at the 2017 code
coverage BoF [1]. The thinking was that using `linkonce_odr` to merge
duplicates is simpler than alternatives like teaching build systems
about a coverage-aware database/module/etc on the side.

- Revising the format is expensive due to the backwards compatibility
requirement, so we might as well compress filenames while we're at it.
This shrinks the encoded filenames in llc by 86% (12MB -> 1.6MB).

See CoverageMappingFormat.rst for the details on what exactly has
changed.

Fixes PR34533 [2], hopefully.

[1] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118428.html
[2] https://bugs.llvm.org/show_bug.cgi?id=34533

Differential Revision: https://reviews.llvm.org/D69471

show more ...

[Alignment][NFC] Move and type functions from MathExtras to Alignment

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pi

[Alignment][NFC] Move and type functions from MathExtras to Alignment

Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D68942

llvm-svn: 374773

show more ...

[Object] Extend MachOUniversalBinary::getObjectForArch

Make the method MachOUniversalBinary::getObjectForArch return MachOUniversalBinary::ObjectForArch
and add helper methods MachOUniversalBinary::

[Object] Extend MachOUniversalBinary::getObjectForArch

Make the method MachOUniversalBinary::getObjectForArch return MachOUniversalBinary::ObjectForArch
and add helper methods MachOUniversalBinary::getMachOObjectForArch, MachOUniversalBinary::getArchiveForArch
for those who explicitly expect to get a MachOObjectFile or an Archive.

Differential revision: https://reviews.llvm.org/D67700

Test plan: make check-all

llvm-svn: 372278

show more ...

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013

show more ...

Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return Expected<>"

Changes: no changes. A fix for the clang code will be landed right on top.

Original commit message:

SectionRef

Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return Expected<>"

Changes: no changes. A fix for the clang code will be landed right on top.

Original commit message:

SectionRef::getName() returns std::error_code now.
Returning Expected<> instead has multiple benefits.

For example, it forces user to check the error returned.
Also Expected<> may keep a valuable string error message,
what is more useful than having a error code.
(Object\invalid.test was updated to show the new messages printed.)

This patch makes a change for all users to switch to Expected<> version.

Note: in a few places the error returned was ignored before my changes.
In such places I left them ignored. My intention was to convert the interface
used, and not to improve and/or the existent users in this patch.
(Though I think this is good idea for a follow-ups to revisit such places
and either remove consumeError calls or comment each of them to clarify why
it is OK to have them).

Differential revision: https://reviews.llvm.org/D66089

llvm-svn: 368826

show more ...

Revert r368812 "[llvm/Object] - Convert SectionRef::getName() to return Expected<>"

It broke clang BB: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16455

llvm-svn: 368813

[llvm/Object] - Convert SectionRef::getName() to return Expected<>

SectionRef::getName() returns std::error_code now.
Returning Expected<> instead has multiple benefits.

For example, it forces user

[llvm/Object] - Convert SectionRef::getName() to return Expected<>

SectionRef::getName() returns std::error_code now.
Returning Expected<> instead has multiple benefits.

For example, it forces user to check the error returned.
Also Expected<> may keep a valuable string error message,
what is more useful than having a error code.
(Object\invalid.test was updated to show the new messages printed.)

This patch makes a change for all users to switch to Expected<> version.

Note: in a few places the error returned was ignored before my changes.
In such places I left them ignored. My intention was to convert the interface
used, and not to improve and/or the existent users in this patch.
(Though I think this is good idea for a follow-ups to revisit such places
and either remove consumeError calls or comment each of them to clarify why
it is OK to have them).

Differential revision: https://reviews.llvm.org/D66089

llvm-svn: 368812

show more ...

[Coverage] Speculative fix for r363325 for an older compiler

It looks like an older version of gcc can't figure out that it needs to
move a unique_ptr while implicitly constructing an Expected objec

[Coverage] Speculative fix for r363325 for an older compiler

It looks like an older version of gcc can't figure out that it needs to
move a unique_ptr while implicitly constructing an Expected object.

llvm-svn: 363342

show more ...

[Coverage] Load code coverage data from archives

Support loading code coverage data from regular archives, thin archives,
and from MachO universal binaries which contain archives.

Testing: check-ll

[Coverage] Load code coverage data from archives

Support loading code coverage data from regular archives, thin archives,
and from MachO universal binaries which contain archives.

Testing: check-llvm, check-profile (with {A,UB}San enabled)

rdar://51538999

Differential Revision: https://reviews.llvm.org/D63232

llvm-svn: 363325

show more ...

Recommit [Object] Change object::SectionRef::getContents() to return Expected<StringRef>

r360876 didn't fix 2 call sites in clang.

Expected<ArrayRef<uint8_t>> may be better but use Expected<StringR

Recommit [Object] Change object::SectionRef::getContents() to return Expected<StringRef>

r360876 didn't fix 2 call sites in clang.

Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now.

Follow-up of D61781.

llvm-svn: 360892

show more ...

Revert r360876 "[Object] Change object::SectionRef::getContents() to return Expected<StringRef>"

It broke the Clang build, see llvm-commits thread.

> Expected<ArrayRef<uint8_t>> may be better but u

Revert r360876 "[Object] Change object::SectionRef::getContents() to return Expected<StringRef>"

It broke the Clang build, see llvm-commits thread.

> Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now.
>
> Follow-up of D61781.

llvm-svn: 360878

show more ...

[Object] Change object::SectionRef::getContents() to return Expected<StringRef>

Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now.

Follow-up of D61781.

llvm-svn: 360876