Skip to content
This repository was archived by the owner on Mar 28, 2020. It is now read-only.

Code coverage and UBSan bug fixes for 4.1 (clang) #146

Closed
wants to merge 6 commits into from

Conversation

vedantk
Copy link
Member

@vedantk vedantk commented Dec 15, 2017

No description provided.

vedantk and others added 6 commits December 14, 2017 18:11

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Emit a gap area starting after the r-paren location and ending at the
start of the body for the braces-optional statements (for, for-each,
while, etc). The count for the gap area equal to the body's count. This
extends the fix in r317758.

Fixes PR35387, rdar://35570345

Testing: stage2 coverage-enabled build of clang, check-clang

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319373 91177308-0d34-0410-b5e6-96231b3b80d8
(cherry picked from commit 715ada5)

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Non-determinism is confusing at best.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320533 91177308-0d34-0410-b5e6-96231b3b80d8
(cherry picked from commit 93d27e3)

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
There is no way to apply sanitizer suppressions to ObjC blocks. A
reasonable default is to have blocks inherit their parent's sanitizer
options.

rdar://32769634

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320132 91177308-0d34-0410-b5e6-96231b3b80d8
(cherry picked from commit 4ae9615)

 Conflicts:
	lib/CodeGen/CGBlocks.cpp
Teach UBSan's bounds check to opportunistically use pass_object_size
information to check array accesses.

rdar://33272922

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320128 91177308-0d34-0410-b5e6-96231b3b80d8
(cherry picked from commit 3df3793)
This is a follow-up to r320128. Eli pointed out that there is some gray
area in the language standard about whether the constant size is exact,
or a lower bound.

https://reviews.llvm.org/D40940

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320185 91177308-0d34-0410-b5e6-96231b3b80d8
(cherry picked from commit 700e3d5)
Lifting from Bob Wilson's notes: The hash value that we compute and
store in PGO profile data to detect out-of-date profiles does not
include enough information. This means that many significant changes to
the source will not cause compiler warnings about the profile being out
of date, and worse, we may continue to use the outdated profile data to
make bad optimization decisions.  There is some tension here because
some source changes won't affect PGO and we don't want to invalidate the
profile unnecessarily.

This patch adds a new hashing scheme which is more sensitive to loop
nesting, conditions, and out-of-order control flow. Here are examples
which show snippets which get the same hash under the current scheme,
and different hashes under the new scheme:

Loop Nesting Example
--------------------

  // Snippet 1
  while (foo()) {
    while (bar()) {}
  }

  // Snippet 2
  while (foo()) {}
  while (bar()) {}

Condition Example
-----------------

  // Snippet 1
  if (foo())
    bar();
  baz();

  // Snippet 2
  if (foo())
    bar();
  else
    baz();

Out-of-order Control Flow Example
---------------------------------

  // Snippet 1
  while (foo()) {
    if (bar()) {}
    baz();
  }

  // Snippet 2
  while (foo()) {
    if (bar())
      continue;
    baz();
  }

In each of these cases, it's useful to differentiate between the
snippets because swapping their profiles gives bad optimization hints.

The new hashing scheme considers some logical operators in an effort to
detect more changes in conditions. This isn't a perfect scheme. E.g, it
does not produce the same hash for these equivalent snippets:

  // Snippet 1
  bool c = !a || b;
  if (d && e) {}

  // Snippet 2
  bool f = d && e;
  bool c = !a || b;
  if (f) {}

This would require an expensive data flow analysis. Short of that, the
new hashing scheme looks reasonably complete, based on a scan over the
statements we place counters on.

Profiles which use the old version of the PGO hash remain valid and can
be used without issue (there are tests in tree which check this).

rdar://17068282

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318229 91177308-0d34-0410-b5e6-96231b3b80d8

(cherry picked from commit 2e3617c)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant