Summary:
This change implements the profile loading functionality in LLVM to
support XRay's profiling mode in compiler-rt.

We introduce a type named `llvm::xray::Profile` which allows building a
profile representation. We can load an XRay profile from a file to build
Profile instances, or do it manually through the Profile type's API.

The intent is to get the `llvm-xray` tool to generate `Profile`
instances and use that as the common abstraction through which all
conversion and analysis can be done. In the future we can generate
`Profile` instances from `Trace` instances as well, through conversion
functions.

Some of the key operations supported by the `Profile` API are:

- Path interning (`Profile::internPath(...)`) which returns a unique path
  identifier.

- Block appending (`Profile::addBlock(...)`) to add thread-associated
  profile information.

- Path ID to Path lookup (`Profile::expandPath(...)`) to look up a
  PathID and return the original interned path.

- Block iteration.

A 'Path' in this context represents the function call stack in
leaf-to-root order. This is represented as a path in an internally
managed prefix tree in the `Profile` instance. Having a handle (PathID)
to identify the unique Paths we encounter for a particular Profile
allows us to reduce the amount of memory required to associate profile
data to a particular Path.

This is the first of a series of patches to migrate the `llvm-stacks`
tool towards using a single profile representation.

Depends on D48653.

Reviewers: kpw, eizan

Reviewed By: kpw

Subscribers: kpw, thakis, mgorny, llvm-commits, hiraditya

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

llvm-svn: 341012

Now that all _zx_vmar_... calls have been updated, we can undo the
change made in r337801 and switch over to the new calls.

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

llvm-svn: 341011

We don't have enough information to know if struct types being
bitcast will cause validation failures or not, so be conservative
and allow such cases to persist (fot now).

Fixes: https://bugs.llvm.org/show_bug.cgi?id=38711

Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits

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

llvm-svn: 341010

how we parse source code.

Instead of implicitly opting all undocumented attributes out of '#pragma
clang attribute' support, explicitly opt them all out and remove the
documentation check from TableGen.

(No new attributes should be added without documentation, so this has
little chance of backsliding. We already support the pragma on one
undocumented attribute, so we don't even want to enforce our old
"rule".)

No functionality change intended.

llvm-svn: 341009

Summary:
Global variables that are external and zero initialized are
supposed to be merged with global variables in the bss section
rather than the data section.

Reviewers: efriedma, rengolin, t.p.northover, javed.absar, asl, john.brawn, pcc

Reviewed By: efriedma

Subscribers: dmgreen, llvm-commits

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

llvm-svn: 341008

[hwasan] add a simple threaded UAF test, make it work on x86 (need to disable tagging in malloc with inside pthread_create)

llvm-svn: 341007

... and remove the dummy implementations from the languages that do not
support it.

llvm-svn: 341006

llvm-svn: 341005

llvm-svn: 341004

Summary:
The syntax highlighting feature so far is mutually exclusive with the lldb feature
that marks the current column in the line by underlining it via an ANSI color code.
Meaning that if you enable one, the other is automatically disabled by LLDB.

This was caused by the fact that both features inserted color codes into the the
source code and were likely to interfere with each other (which would result
in a broken source code printout to the user).

This patch moves the cursor code into the highlighting framework, which provides
the same feature to the user in normal non-C source code. For any source code
that is highlighted by Clang, we now also have cursor marking for the whole token
that is under the current source location. E.g., before we underlined only the '!' in the
expression '1 != 2', but now the whole token '!=' is underlined. The same for function
calls and so on. Below you can see two examples where we before only underlined
the first character of the token, but now underline the whole token.

{F7075400}
{F7075414}

It also simplifies the DisplaySourceLines method in the SourceManager as most of
the code in there was essentially just for getting this column marker to work as
a FormatEntity.

Reviewers: aprantl

Reviewed By: aprantl

Subscribers: lldb-commits

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

llvm-svn: 341003

llvm-svn: 341002

The cost modeling was not accounting for the fact we were duplicating the instruction once per predecessor.  With a default threshold of 1, this meant we were actually creating #pred copies.

Adding to the fun, there is *absolutely no* test coverage for this.  Simply bailing for more than one predecessor passes all checked in tests.

llvm-svn: 341001

These bugs were found by writing a Python script which spidered
the entire Chromium build directory tree demangling every symbol
in every object file.  At the start, the tool printed:

  Processed 27443 object files.
  2926377/2936108 symbols successfully demangled (99.6686%)
  9731 symbols could not be demangled (0.3314%)
  14589 files crashed while demangling (53.1611%)

After this patch, it prints:

  Processed 27443 object files.
  41295518/41295617 symbols successfully demangled (99.9998%)
  99 symbols could not be demangled (0.0002%)
  0 files crashed while demangling (0.0000%)

The issues fixed in this patch are:

  * Ignore empty parameter packs.  Previously we would encounter
    a mangling for an empty parameter pack and add a null node
    to the AST.  Since we don't print these anyway, we now just
    don't add anything to the AST and ignore it entirely.  This
    fixes some of the crashes.

  * Account for "incorrect" string literal demanglings.  Apparently
    an older version of clang would not truncate mangled string
    literals to 32 bytes of encoded character data.  The demangling
    code however would allocate a 32 byte buffer thinking that it
    would not encounter more than this, and overrun the buffer.
    We now demangle up to 128 bytes of data, since the buggy
    clang would encode up to 32 *characters* of data.

  * Extended support for demangling init-fini stubs.  If you had
    something like
      struct Foo {
        static vector<string> S;
      };
    this would generate a dynamic atexit initializer *for the
    variable*.  We didn't handle this, but now we print something
    nice.  This is actually an improvement over undname, which will
    fail to demangle this at all.

  * Fixed one case of static this adjustment.  We weren't handling
    several thunk codes so we didn't recognize the mangling.  These
    are now handled.

  * Fixed a back-referencing problem.  Member pointer templates
    should have their components considered for back-referencing

The remaining 99 symbols which can't be demangled are all symbols
which are compiler-generated and undname can't demangle either.

llvm-svn: 341000

This should more accurately reflect what the AsmPrinter will actually
do.

This is NFC, as far as I can tell; all the places that might be affected
already have an extra check to avoid using the result of
getPreferredAlignment in this situation.

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

llvm-svn: 340999

These symbols are declared early with the same value, so they otherwise
appear identical to ICF.

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

llvm-svn: 340998

llvm-svn: 340997

The restoreDateOnFile() method used to preserve dates uses sys::fs::openFileForWrite(). That method defaults to opening files with CD_CreateAlways, which truncates the output file if it exists. Use CD_OpenExisting instead to open it and *not* truncate it, which also has the side benefit of erroring if the file does not exist (it should always exist, because we just wrote it out).

Also, fix the test case to make sure the output is a valid output file, and not empty. The extra test assertions are enough to catch this regression.

llvm-svn: 340996

llvm-svn: 340995

read/understand/maintain.

As a side-effect, this should also improve the performance by avoiding
costly vector element removals and switching from a std::map to a
SmallDenseSet.

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

llvm-svn: 340994

On AMDGPU we have 70 register classes, so iterating over all 70
each time and exiting is costly on the CPU, this flips the loop
around so that it loops over the 70 register classes first,
and exits without doing the inner loop if needed.

On my test just starting radv this takes
RegUsageInfoCollector::runOnMachineFunction
from 6.0% of total time to 2.7% of total time,
and reduces the startup from 2.24s to 2.19s

Patch by David Airlie!

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

llvm-svn: 340993

Last week, someone noted that a couple of the time_point member functions were not constexpr. I looked, and they were right. They were made constexpr in p0505, so I looked at all the other bits in that paper to make sure that I didn't miss anything else. There were a couple methods in the synopsis that should have been marked constexpr, but the code was correct.

llvm-svn: 340992

It broke the clang-cl self-host.

llvm-svn: 340991

Add assertions to verify that.

llvm-svn: 340990

llvm-svn: 340989

Summary:
D48465 is currently blocked by the fact that tab-completing the first expression is deadlocking LLDB.

The reason for this deadlock is that when we push the ProcessIO handler for reading the Objective-C runtime
information from the executable (which is triggered when we parse the an expression for the first time),
the IOHandler can't be pushed as the Editline::Cancel method is deadlocking.

The deadlock in Editline is coming from the m_output_mutex, which is locked before we go into tab completion.
Even without this lock, calling Cancel on Editline will mean that Editline cleans up behind itself and deletes the
current user-input, which is screws up the console when we are tab-completing at the same time.

I think for now the most reasonable way of fixing this is to just not call Cancel on the current IOHandler when we push
the IOHandler for running an internal utility function.

As we can't really write unit tests for IOHandler itself (due to the hard dependency on an initialized Debugger including
all its global state) and Editline completion is currently also not really testable in an automatic fashion, the test for this has
to be that the expression command completion in D48465 doesn't fail when requesting completion the first time.

A more precise test plan for this is:

1. Apply D48465.
2. Start lldb and break in some function.
3. Type `expr foo` and press tab to request completion.
4. Without this patch, we deadlock and LLDB stops responding.

I'll provide an actual unit test for this once I got around and made the IOHandler code testable,
but for now unblocking D48465 is more critical.

Thanks to Jim for helping me debugging this.

Reviewers: jingham

Reviewed By: jingham

Subscribers: emaste, clayborg, abidh, lldb-commits

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

llvm-svn: 340988

Summary: This wasn't documented https://clang.llvm.org/docs/AttributeReference.html, and briefly mentioned https://clang.llvm.org/docs/UsersManual.html#differences-between-various-standard-modes.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: efriedma, cfe-commits, srhines

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

llvm-svn: 340987

rdar://13729267

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

llvm-svn: 340986

llvm-svn: 340985

Introduce a new MemRegion sub-class, CXXDerivedObjectRegion, which is
the opposite of CXXBaseObjectRegion, to represent such casts. Such region is
a bit weird because it is by design bigger than its super-region.
But it's not harmful when it is put on top of a SymbolicRegion
that has unknown extent anyway.

Offset computation for CXXDerivedObjectRegion and proper modeling of casts
still remains to be implemented.

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

llvm-svn: 340984

llvm-svn: 340983

Don't try to understand what's going on when there's a C++ method called eg.
CFRetain().

Refactor the checker a bit, to use more modern APIs.

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

llvm-svn: 340982

llvm-svn: 340981

llvm-svn: 340980

llvm-svn: 340979

llvm-svn: 340978

The analyzer doesn't make use of them anyway and they seem to have
pretty weird AST from time to time, so let's just skip them for now.

Fixes a crash reported as pr37769.

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

llvm-svn: 340977

Summary:
This was an experimental feature. After evaluating it with:

1) https://github.com/google/fuzzer-test-suite/tree/master/engine-comparison

2) enabling on real world fuzz targets running at ClusterFuzz and OSS-Fuzz

The following conclusions were made:

1) With fuzz targets that have reached a code coverage plateau, the feature does
   not improve libFuzzer's ability to discover new coverage and may actually
   negatively impact it.

2) With fuzz targets that have not yet reached a code coverage plateau, the
   feature might speed up new units discovery in some cases, but it is quite
   rare and hard to confirm with a high level on confidence.

Revert of https://reviews.llvm.org/D48054 and https://reviews.llvm.org/D49621.

Reviewers: metzman, morehouse

Reviewed By: metzman, morehouse

Subscribers: delcypher, #sanitizers, llvm-commits, kcc

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

llvm-svn: 340976

The analyzer doesn't make use of them anyway and they seem to have
pretty weird AST from time to time, so let's just skip them for now.

Fixes pr37769.

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

llvm-svn: 340975

Teach LICM to hoist stores out of loops when the store writes to a location otherwise unused in the loop, writes a value which is invariant, and is guaranteed to execute if the loop is entered.

Worth noting is that this transformation is partially overlapping with the existing promotion transformation. Reasons this is worthwhile anyway include:
 * For multi-exit loops, this doesn't require duplication of the store.
 * It kicks in for case where we can't prove we exit through a normal exit (i.e. we may throw), but can prove the store executes before that possible side exit.

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

llvm-svn: 340974

[hwasan] simplify the realloc implementation: always allocate/deallocate on realloc. This may slowdown some realloc-heavy code, but at least at this point a want simpler code. Also added a test

llvm-svn: 340973