Implementation of remote packets for Trace data.

Summary:
The changes consist of new packets for trace manipulation and
trace collection. The new packets are also documented. The packets
are capable of providing custom trace specific parameters to start
tracing and also retrieve such configuration from the server.

Reviewers: clayborg, lldb-commits, tberghammer, labath, zturner

Reviewed By: clayborg, labath

Subscribers: krytarowski, lldb-commits

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

llvm-svn: 303972

Re-enable "[SCEV] Do not fold dominated SCEVUnknown into AddRecExpr start"

The patch rL303730 was reverted because test lsr-expand-quadratic.ll failed on
many non-X86 configs with this patch. The reason of this is that the patch
makes a correctless fix that changes optimizer's behavior for this test.
Without the change, LSR was making an overconfident simplification basing on a
wrong SCEV. Apparently it did not need the IV analysis to do this. With the
change, it chose a different way to simplify (that wasn't so confident), and
this way required the IV analysis. Now, following the right execution path,
LSR tries to make a transformation relying on IV Users analysis. This analysis
is target-dependent due to this code:

  // LSR is not APInt clean, do not touch integers bigger than 64-bits.
  // Also avoid creating IVs of non-native types. For example, we don't want a
  // 64-bit IV in 32-bit code just because the loop has one 64-bit cast.
  uint64_t Width = SE->getTypeSizeInBits(I->getType());
  if (Width > 64 || !DL.isLegalInteger(Width))
    return false;

To make a proper transformation in this test case, the type i32 needs to be
legal for the specified data layout. When the test runs on some non-X86
configuration (e.g. pure ARM 64), opt gets confused by the specified target
and does not use it, rejecting the specified data layout as well. Instead,
it uses some default layout that does not treat i32 as a legal type
(currently the layout that is used when it is not specified does not have
legal types at all). As result, the transformation we expect to happen does
not happen for this test.

This re-enabling patch does not have any source code changes compared to the
original patch rL303730. The only difference is that the failing test is
moved to X86 directory and now has requirement of running on x86 only to comply
with the specified target triple and data layout.

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

llvm-svn: 303971

LivePhysRegs: Skip reserved regs in computeLiveIns; NFCI

Re-commit r303937 + r303949 as they were not the cause for the build
failures.

We do not track liveness of reserved registers so adding them to the
liveins list in computeLiveIns() was completely unnecessary.

llvm-svn: 303970

Revert rL303923 since it broke the sanitizer bootstrap build bot.

llvm-svn: 303969

[InstSimplify] Use APInt::isMask isntead of manually implementing it. NFC

llvm-svn: 303968

[InstSimplify] Use m_ConstantInt matchers to short some code. NFC

llvm-svn: 303967

Workaround debug info bug in Clangs coroutine implementation

llvm-svn: 303966

FreeBSD ProcessMonitor: map TRAP_CAP to a trace trap

In the absense of a more specific handler for TRAP_CAP (generated by
ENOTCAPABLE or ECAPMODE while in capability mode) treat it as a trace
trap. Obtained from FreeBSD r318884.

We should later add an option to have LLDB control the trapcap procctl
(as with ASLR), as well as report a specific stop reason. For now this
change eliminates an assertion failure from LLDB.

llvm-svn: 303965

[IR] Add an iterator and range accessor for the PHI nodes of a basic
block.

This allows writing much more natural and readable range based for loops
directly over the PHI nodes. It also takes advantage of the same tricks
for terminating the sequence as the hand coded versions.

I've replaced one example of this mostly to showcase the difference and
I've added a unit test to make sure the facilities really work the way
they're intended. I want to use this inside of SimpleLoopUnswitch but it
seems generally nice.

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

llvm-svn: 303964

Get <experimental/coroutine> working in C++03.

Clang supports coroutines in all dialects; Therefore libc++ should too,
otherwise the Clang extension is unusable.

I'm not convinced extending support to C++03 is a feasible long term
plan, since as the library grows to offer things like generators it
will be come increasingly difficult to limit the implementation to C++03.

However for the time being supporting C++03 isn't a big deal.

llvm-svn: 303963

[docs] Point coroutine link to an actual document

Unsure if there's a better document, but what we had before led to a
404. :)

llvm-svn: 303962

Rearrange code for the sake of readability. NFC.

llvm-svn: 303961

Revert "LivePhysRegs: Fix addLiveOutsNoPristines() for return blocks past PEI"

Tentatively revert this to see if it fixes the buildbot stage2
breakages.

This reverts commit r303938.
This reverts commit r303954.

llvm-svn: 303960

Simplify. NFC.

llvm-svn: 303959

Inline a trivial constructor.

llvm-svn: 303958

Create valid LValue to represent null pointers in constant exprs

We were leaving the SubobjectDesignator in a surprising situation, where
it was allegedly valid but didn't actually refer to a type. This caused
a crash later on.

This patch fills out the SubobjectDesignator with the pointee type (as
happens in other evaluations of constant pointers) so that we don't
crash later.

llvm-svn: 303957

Guard <experimental/coroutine> against older Clang versions.

Clang started providing -fcoroutines and defining __cpp_coroutines
way before it implemented the __builtin_coro_foo functions. This
means that simply checking if __cpp_coroutines is not a sufficient
way of detecting the actual feature.

This patch implements _LIBCPP_HAS_NO_COROUTINES which implements
a slightly more complex feature check. Specifically it requires
__cpp_coroutines >= 201703L, which only holds for Clang 5.0 built
after 2017/05/24.

llvm-svn: 303956

Revert "LivePhysRegs: Skip reserved regs in computeLiveIns; NFCI"

Tentatively revert, suspecting that it caused breakage in stage2
buildbots.

This reverts commit r303949.
This reverts commit r303937.

llvm-svn: 303955

Test for r303938

llvm-svn: 303954

Remove incorrect #ifdef guards around variant tests.

The tests were previously guarded by #if defined(_LIBCPP_VER) || defined(_MSVC_STL_VER),
which is both incorrect (e.g. _LIBCPP_VERSION) and unneeded. Although the tests are
technically non-standard (yet) they are supported by both libc++ and MSVC's STL.

libstdc++ doesn't regularly use the test suite so I'm not concerned about guarding these
tests for them.

llvm-svn: 303953

[PM] Enable the new simple loop unswitch pass in the new pass manager
(where it is the only realistic option).

This passes the LLVM test suite for me, but I'm clearly still hammering
on this.

llvm-svn: 303952

[test] Fix breakage from r303947 =(

llvm-svn: 303951

Tidy up RelocVisitor.h.

Summary:
RelocVisitor had too many, too small functions. This patch group them
by architecture rather than each relocation type.

Reviewers: grimar, dblaikie

Subscribers: llvm-commits

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

llvm-svn: 303950

LivePhysRegs: Follow-up to r303937

We may have situations in which a superregister is reserved and not
added to liveins, so we have to add the subregisters.

llvm-svn: 303949

Remove dummy cast. NFC.

llvm-svn: 303948

[test] make_shared<T()>(...) is, uh, libc++-specific

llvm-svn: 303947

[llvm-pdbdump] Don't crash when displaying padding.

We have a lot of complicated logic to determine where padding
is in a record, and the debug info doesn't always provide enough
information to figure it out with laser precision.  In this case
we were putting the padding in the wrong place causing an
out of bounds access on a BitVector.

Right now we decide that any trailing padding of a child type
will be truncated during record layout, but this is only true
insofar as the class still is sized properly to end on an
alignment boundary, which the algorithm doesn't yet know about.

For now, just don't crash, even though we display padding twice
in this case.

llvm-svn: 303946

Factor resolving of header directives -> files out of module map parser.

llvm-svn: 303945

[Examples] Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 303944

Return a lit.Test.Result object from TestRunner's executeShTest()

Summary:
For various clang analyzer tests, which were unsupported, I got lit
exceptions, similar to the following:

    Exception during script execution:
    Traceback (most recent call last):
      File "utils/lit/lit/run.py", line 190, in execute_test
        result = test.config.test_format.execute(test, lit_config)
      File "tools/clang/test/Analysis/analyzer_test.py", line 11, in execute
        if result.code == lit.Test.FAIL:
    AttributeError: 'tuple' object has no attribute 'code'

This is because executeShTest() in utils/lit/lit/TestRunner.py is
supposed to return a lit.Test.Result object, but in case of unsupported
tests, it returns a plain tuple.

Fix this by returning a properly initialized lit.Test.Result object
instead.

Reviewers: rnk, rafael, modocache

Subscribers: llvm-commits

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

llvm-svn: 303943

Remove unused member.

llvm-svn: 303942

[compiler-rt] Replace allow_user_segv_handler=0 with kHandleSignalExclusive

Summary:
allow_user_segv_handler had confusing name did not allow to control behavior for
signals separately.

Reviewers: eugenis, alekseyshl, kcc

Subscribers: llvm-commits, dberris, kubamracek

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

llvm-svn: 303941

[PPC] Add text for assert.

llvm-svn: 303940

LTO: Do summary-based prevailing symbol resolution at --lto-O0.

Prevailing symbol resolution is necessary for correctness. Without
this we can end up dropping a referenced linkonce symbol from the link.

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

llvm-svn: 303939

LivePhysRegs: Fix addLiveOutsNoPristines() for return blocks past PEI

- addLiveOutsNoPristines() needs to add callee saved registers that are
  actually saved and restored somewhere to the set (they are not
  pristine).
- Cleanup/rewrite the code for addLiveOuts()/addLiveOutsNoPristines().

This fixes the problem from D32156.

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

llvm-svn: 303938

LivePhysRegs: Skip reserved regs in computeLiveIns; NFCI

We do not track liveness of reserved registers so adding them to the
liveins list in computeLiveIns() was completely unnecessary.

llvm-svn: 303937

Re-add <experimental/coroutine> to the module map.

The original issues were caused because <experimental/coroutine>
didn't correctly #ifdef out enough of the header, which caused incomplete
types to be used.

This patch fixes the `#if defined(__cpp_coroutines)` guard and re-adds
the headers to the module map.

It also uglifies some incorrectly non-reserved names.

llvm-svn: 303936

[CV Type Merging] Find nested type indices faster.

Merging two type streams is one of the most time consuming
parts of generating a PDB, and as such it needs to be as
fast as possible.  The visitor abstractions used for interoperating
nicely with many different types of inputs and outputs have
been used widely and help greatly for testability and implementing
tools, but the abstractions build up and get in the way of
performance.

This patch removes all of the visitation stuff from the type
stream merger, essentially re-inventing the leaf / member switch
and loop, but at a very low level.  This allows us many other
optimizations, such as not actually deserializing *any* records
(even member records which don't describe their own length), as
the operation of "figure out how long this record is" is somewhat
faster than "figure out how long this record *and* get all its
fields out".  Furthermore, whereas before we had to deserialize,
re-write type indices, then re-serialize, now we don't have to
do any of those 3 steps.  We just find out where the type indices
are and pull them directly out of the byte stream and re-write
them.

This is worth a 50-60% performance increase.  On top of all other
optimizations that have been applied this week, I now get the
following numbers when linking lld.exe and lld.pdb

MSVC: 25.67s
Before This Patch: 18.59s
After This Patch: 8.92s

So this is a huge performance win.

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

llvm-svn: 303935

"*" => "+" to avoid matching on empty string.

llvm-svn: 303934

DebugInfo: Simplify scopes+subprogram handling since the subprogram<>cu link inversion

Previously this code was defensive to the situation in which the debug
info scopes would lead to a different subprogram from the subprogram in
the CU's subprogram list (this could've happened with linkonce
functions, etc as per the comment being removed). Since the CU<>SP link
reversal this is no longer possible.

llvm-svn: 303933

Make test/Driver/baremetal.cpp work when output directory isn't named 'bin'.

llvm-svn: 303932

[PPC] Fix atomics lowering in DAG lowering.

I forgot to forward the chain, causing some missing instruction
dependencies. The test crashes the compiler without this patch.

Inspired by the test case, D33519 also tries to remove the extra sync.

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

llvm-svn: 303931

Switch from using a DiagnosticTrap and a note for "while defining a special
member function" context notes to registering an entry on the context stack.

Also reorder the steps within defining special members to be consistent.

This has a few benefits: if multiple diagnostics are produced while checking
such a member, the note is now attached to the first such diagnostic rather
than the last, this prepares us for persisting these diagnostics between the
point at which we require the implicit instantiation of a template and the
point at which that instantiation is actually performed, and this fixes some
cases where we would fail to produce a full note stack leading back to user
code in the case of such a diagnostic.

The reordering exposed a case where we could recursively attempt to define a
defaulted destructor while we're already defining one (and other such cases
also appear to be possible, with or without this change), so this change also
reuses the "willHaveBody" flag on function declarations to track that we're in
the middle of synthesizing a body for the function and bails out if we try to
define a function that we're already defining.

llvm-svn: 303930

Correct typo: LIBCXXABI_BUILTINS_LIBRARY -> LIBCXX_BUILTINS_LIBRARY

llvm-svn: 303929

libcxx: fix bootstrapping for mingw-w64

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

llvm-svn: 303928

Fix test to handle running on platforms which don't enable pubnames at all

Check that there are no entries in the pub sections, but that they may
either be not present or present-but-empty.

llvm-svn: 303927

When uncompressing sections, remove SHF_COMPRESSED bits. NFC.

In this way, the content and the flag is always consistent, which I
think better than removing the bit when input sections reaches the Writer.

llvm-svn: 303926

Revert "Simplify a variable type by using StringRef instead of CachedHashStringRef."

This reverts commit r303787.

It caused a slowdown in fast links. That is, links with no debug info
or optimizations.

llvm-svn: 303925

[InstCombine] Add an InstCombine specific wrapper around isKnownToBeAPowerOfTwo to shorten code. NFC

We have wrappers for several other ValueTracking methods that take care of passing all of the analysis and assumption cache parameters. This extends it to isKnownToBeAPowerOfTwo.

llvm-svn: 303924

[GVN] Add phi-translate support in scalarpre.

Right now scalarpre doesn't have phi-translate support, so it will miss some
simple pre opportunities. Like the following testcase, current scalarpre cannot
recognize the last "a * b" is fully redundent because a and b used by the last
"a * b" expr are both defined by phis.

  long a[100], b[100], g1, g2, g3;
  __attribute__((pure)) long goo();

  void foo(long a, long b, long c, long d) {
    g1 = a * b;
    if (__builtin_expect(g2 > 3, 0)) {
      a = c;
      b = d;
      g2 = a * b;
    }
    g3 = a * b;      // fully redundant.
  }

The patch adds phi-translate support in scalarpre. This is only a temporary
solution before the newpre based on newgvn is available.

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

llvm-svn: 303923

Add constrained intrinsics for some libm-equivalent operations

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

llvm-svn: 303922

CodeGen: Rename DEBUG_TYPE to match passnames

Rename the DEBUG_TYPE to match the names of corresponding passes where
it makes sense. Also establish the pattern of simply referencing
DEBUG_TYPE instead of repeating the passname where possible.

llvm-svn: 303921

[lld] Fix a bug where we continually re-follow type servers.

Originally this was intended to be set up so that when linking
a PDB which refers to a type server, it would only visit the
PDB once, and on subsequent visitations it would just skip it
since all the records had already been added.

Due to some C++ scoping issues, this was not occurring and it
was revisiting the type server every time, which caused every
record to end up being thrown away on all subsequent visitations.

This doesn't affect the performance of linking clang-cl generated
object files because we don't use type servers, but when linking
object files and libraries generated with /Zi via MSVC, this means
only 1 object file has to be linked instead of N object files, so
the speedup is quite large.

llvm-svn: 303920

[CodeView Type Merging] Don't keep re-allocating temp serializer.

Previously, every time we wanted to serialize a field list record, we
would create a new copy of FieldListRecordBuilder, which would in turn
create a temporary instance of TypeSerializer, which itself had a
std::vector<> that was about 128K in size. So this 128K allocation was
happening every time. We can re-use the same instance over and over, we
just have to clear its internal hash table and seen records list between
each run. This saves us from the constant re-allocations.

This is worth an ~18.5% speed increase (3.75s -> 3.05s) in my tests.

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

llvm-svn: 303919

Make BinaryStreamReader::readCString a bit faster.

Previously it would do a character by character search for a null
terminator, to account for the fact that an arbitrary stream need not
store its data contiguously so you couldn't just do a memchr. However, the
stream API has a function which will return the longest contiguous chunk
without doing a copy, and by using this function we can do a memchr on the
individual chunks. For certain types of streams like data from object
files etc, this is guaranteed to find the null terminator with only a
single memchr, but even with discontiguous streams such as
MappedBlockStream, it's rare that any given string will cross a block
boundary, so even those will almost always be satisfied with a single
memchr.

This optimization is worth a 10-12% reduction in link time (4.2 seconds ->
3.75 seconds)

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

llvm-svn: 303918

[pdb] pad source file name buffer at the end instead of the beginning

Summary:
DbiStreamBuilder calculated the offset of the source file names inside
the file info substream as the size of the file info substream minus
the size of the file names. Since the file info substream is padded to
a multiple of 4 bytes, this caused the first file name to be aligned
on a 4-byte boundary. By contrast, DbiModuleList would read the file
names immediately after the file name offset table, without skipping
to the next 4-byte boundary. This change makes it so that the file
names are written to the location where DbiModuleList expects them,
and puts any necessary padding for the file info substream after the
file names instead of before it.

Reviewers: amccarth, rnk, zturner

Reviewed By: amccarth, zturner

Subscribers: llvm-commits

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

llvm-svn: 303917

Fix a bug in MappedBlockStream.

It was using the number of blocks of the entire PDB file as the number
of blocks of each stream that was created.  This was only an issue in
the readLongestContiguousChunk function, which  was never called prior.
This bug surfaced when I updated an algorithm to use this function and
the algorithm broke.

llvm-svn: 303916

[WebAssembly] MC: Include unnamed data when writing wasm files

Also, include global entries for all data symbols, not
just external ones, since these are referenced by the
relocation records.

Add a test case that includes unnamed data.

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

llvm-svn: 303915

[CodeView Type Merging] Avoid record deserialization when possible.

A profile shows the majority of time doing type merging is spent
deserializing records from sequences of bytes into friendly C++ structures
that we can easily access members of in order to find the type indices to
re-write.

Records are prefixed with their length, however, and most records have
type indices that appear at fixed offsets in the record. For these
records, we can save some cycles by just looking at the right place in the
byte sequence and re-writing the value, then skipping the record in the
type stream. This saves us from the costly deserialization of examining
every field, including potentially null terminated strings which are the
slowest, even though it was unnecessary to begin with.

In addition, we apply another optimization. Previously, after
deserializing a record and re-writing its type indices, we would
unconditionally re-serialize it in order to compute the hash of the
re-written record. This would result in an alloc and memcpy for every
record. If no type indices were re-written, however, this was an
unnecessary allocation. In this patch re-writing is made two phase. The
first phase discovers the indices that need to be rewritten and their new
values. This information is passed through to the de-duplication code,
which only copies and re-writes type indices in the serialized byte
sequence if at least one type index is different.

Some records have type indices which only appear after variable length
strings, or which have lists of type indices, or various other situations
that can make it tricky to make this optimization. While I'm not giving up
on optimizing these cases as well, for now we can get the easy cases out
of the way and lay the groundwork for more complicated cases later.

This patch yields another 50% speedup on top of the already large speedups
submitted over the past 2 days. In two tests I have run, I went from 9
seconds to 3 seconds, and from 16 seconds to 8 seconds.

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

llvm-svn: 303914

Update the getting started documentation to match the corresponding LLVM commit in r303912.

llvm-svn: 303913

Update the documentation and CMake file for Visual Studio generators.

By default, CMake uses a 32-bit toolchain, even when on a 64-bit platform targeting a 64-bit build. However, due to the size of the binaries involved, this can cause linker instabilities (such as the linker running out of memory). Guide people to the correct solution to get CMake to use the native toolchain.

llvm-svn: 303912

[asan] relax sanbox_read_proc_self_maps_test to pass even if unshare() fails.

llvm-svn: 303911

Make test/Driver/baremetal.cpp pass on Windows

llvm-svn: 303910

Earlier revert introduced an extra space, remove it.

llvm-svn: 303909

Revert "[AMDGPU] add __builtin_amdgcn_s_getpc"

This reverts commit r303861, the LLVM intrinsic was reverted.

llvm-svn: 303908

Fix bug #28898
lldb: libedit produces garbled, unusable input on Linux

Apply patch from Christos Zoulas, upstream libedit developer.
It has been tested on NetBSD/amd64.

New code supports combination of wide libedit and disabled
LLDB_EDITLINE_USE_WCHAR, which was the popular case on Linux
systems.

llvm-svn: 303907

Fix typo in tls patch

llvm-svn: 303906

Accept not only --reproduce <foo> but also --reproduce=<foo>.

llvm-svn: 303905

PPC: Correct Size for GETtlsADDR

PPC::GETtlsADDR is lowered to a branch and a nop, by the assembly
printer. Its size was incorrectly marked as 4, correct it to 8. The
incorrect size can cause incorrect branch relaxation in
PPCBranchSelector under the right conditions.

llvm-svn: 303904

Add a test for PR33166.

This tests optimized code where a variable is allocated on the
stack for some part of the function.

llvm-svn: 303903

Revert r303859, CodeGen/AMDGPU/llvm.amdgcn.s.getpc.ll fails on bots.

llvm-svn: 303902

[AArch64]: add 'a' inline asm operand modifier.

Summary:
This is used in the Linux kernel, and effectively just means "print an
address". This brings back r193593.

Reviewed by: Renato Golin

Reviewers: t.p.northover, rengolin, richard.barton.arm, kristof.beyls

Subscribers: aemerson, javed.absar, llvm-commits, eraman

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

llvm-svn: 303901

Update more coroutine_handle signatures to reflect N4663.

Thanks to Casey Carter for pointing out the out-of-date tests and
implementation.

llvm-svn: 303900

Add asserts that the nullptr is maintained in string erase operations.

llvm-svn: 303899

Appease more buildbots about r303873

llvm-svn: 303898

Fix SelectionDAGBuilder::getDbgValue to not expect DW_OP_deref on FI vars

This fixes an oversight in r300522, which changed alloca
dbg.values to no longer emit a DW_OP_deref.

The array.ll testcase was regenerated from source.

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

llvm-svn: 303897

Delete an obsolete paragraph in LangRef.

llvm-svn: 303896

Update coroutine_handle<P>::promise to reflect N4663.

This patch updates the promise() member to match the current spec.
Specifically it removes the non-const overload and make the return
type of the const overload non-const.

This patch also makes the ASSERT_NOT_NOEXCEPT tests libc++ specific,
since other implementations may be free to strengthen the specification.

llvm-svn: 303895

DebugInfo: Produce debug_{gnu_}pub{names,types} entries when explicitly requested, even in -gmlt or when empty

Turns out gold doesn't use the DW_AT_GNU_pubnames to decide whether to
parse the rest of the DIEs when building gdb-index. This causes gold to
trip over LLVM's output when there are DW_FORM_ref_addr present.

Gold does use the presence of a debug_gnu_pub{names,types} entry for the
CU to skip parsing the debug_info portion, so make sure that's included
even when empty (technically, when empty there couldn't be any ref_addr
anyway - it only came up when gmlt didn't produce any (even non-empty)
pubnames - but given what that reveals about gold's implementation, this
seems like a good thing to do for consistency).

llvm-svn: 303894

Use MD5::hash(). NFC.

llvm-svn: 303893

[compiler-rt] Make print_module_map description consistent with the rest.

Reviewers: eugenis

Subscribers: llvm-commits, kubamracek

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

llvm-svn: 303892

[llvm-pdbdump] [yaml2pdb] always include object file name in module info

Summary:
Previously, the yaml2pdb subcommand of llvm-pdbdump only
included object file names in module info if a module info stream was
present. This change makes it so that we include the object file name
even if there is no module info stream for the module. As a result,
running
llvm-pdbdump pdb2yaml -dbi-module-info original.pdb > original.yaml &&
llvm-pdbdump yaml2pdb -pdb=new.pdb original.yaml && llvm-pdbdump
pdb2yaml -dbi-module-info new.pdb > new.yaml now produces identical
original.yaml and new.yaml files.

Reviewers: amccarth, zturner

Reviewed By: zturner

Subscribers: fhahn, llvm-commits

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

llvm-svn: 303891

Do not allow delay-importing data symbols.

If you pass /delayload:<dllname> to the COFF linker, it creates thunks
so that DLLs are loaded when they are used for the first time instead of
load-time.

This mechanism do not work for data symbols as there's no way to trap
acccesses to data imported from DLLs. (Technically, I think if we do not
initially map dllimport tables in memory, we could actually trap accesses
and delay-load data symbols, but that's not what Windows do.)

This patch is to report an error when you try to delay-load data symbols.

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

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

llvm-svn: 303890

[test] Remove workaround for C1XX conversion-to-nullptr bug

VSO#391542 "Types can't be convertible to nullptr_t"

Also put internal bug numbers on the workarounds in test_workarounds.h for correlation.

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

llvm-svn: 303889

[test] Workaround C1XX bug in uses_allocator_types.hpp

VSO#109062 "Explicit template argument specification with empty template parameter pack expansion does not imply further empty pack expansion"

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

llvm-svn: 303888

Implement tls scanning for darwin LSan

Summary:
This required for any users who call exit() after creating
thread-specific data, as tls destructors are only called when
pthread_exit() or pthread_cancel() are used. This should also
match tls behavior on linux.

Getting the base address of the tls section is straightforward,
as it's stored as a section offset in %gs. The size is a bit trickier
to work out, as there doesn't appear to be any official documentation
or source code referring to it. The size used in this patch was determined
by taking the difference between the base address and the address of the
subsequent memory region returned by vm_region_recurse_64, which was
1024 * sizeof(uptr) on all threads except the main thread, where it was
larger. Since the section must be the same size on all of the threads,
1024 * sizeof(uptr) seemed to be a reasonable size to use, barring
a more programtic way to get the size.

1024 seems like a reasonable number, given that PTHREAD_KEYS_MAX
is 512 on darwin, so pthread keys will fit inside the region while
leaving space for other tls data. A larger size would overflow the
memory region returned by vm_region_recurse_64, and a smaller size
wouldn't leave room for all the pthread keys. In addition, the
stress test added here passes, which means that we are scanning at
least the full set of possible pthread keys, and probably
the full tls section.

Reviewers: alekseyshl, kubamracek

Subscribers: krytarowski, llvm-commits

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

llvm-svn: 303887

Don't require ThreadState to be contained within tls on all platforms

The existing implementation ran CHECKs to assert that the thread state
was stored inside the tls. However, the mac implementation of tsan doesn't
store the thread state in tls, so these checks fail once darwin tls support
is added to the sanitizers. Only run these checks on platforms where
the thread state is expected to be contained in the tls.

llvm-svn: 303886

Disable two more flaky ASan wait* tests temporarily on Darwin

llvm-svn: 303885

[Documentation] Mention hicpp check group in Clang-tidy main document.

llvm-svn: 303884

[sanitizer] Revert rL303879 as it breaks Windows

Summary:
Apparently Windows's `UnmapOrDie` doesn't support partial unmapping. Which
makes the new region allocation technique not Windows compliant.

Reviewers: alekseyshl, dvyukov

Reviewed By: alekseyshl

Subscribers: llvm-commits, kubamracek

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

llvm-svn: 303883

Revert MSVC CXXOperatorNames patch due to issues with Chromium

llvm-svn: 303882

Revert 303872/303877 since the patch that caused these issues
is also being reverted.

llvm-svn: 303881

Relax testcase to appease buildbots

When lld isn't built, the tests as they were previously, were too picky about
the path to the linker.

llvm-svn: 303880

[sanitizer] Change the 32-bit Primary AllocateRegion to reduce fragmentation

Summary:
Currently, AllocateRegion has a tendency to fragment memory: it allocates
`2*kRegionSize`, and if the memory is aligned, will unmap `kRegionSize` bytes,
thus creating a hole, which can't itself be reused for another region. This
is exacerbated by the fact that if 2 regions get allocated one after another
without any `mmap` in between, the second will be aligned due to mappings
generally being contiguous.

An idea, suggested by @alekseyshl, to prevent such a behavior is to have a
stash of regions: if the `2*kRegionSize` allocation is properly aligned, split
it in two, and stash the second part to be returned next time a region is
requested.

At this point, I thought about a couple of ways to implement this:
 - either an `IntrusiveList` of regions candidates, storing `next` at the
   begining of the region;
 - a small array of regions candidates existing in the Primary.

While the second option is more constrained in terms of size, it offers several
advantages:
 - security wise, a pointer in a region candidate could be overflowed into, and
   abused when popping an element;
 - we do not dirty the first page of the region by storing something in it;
 - unless several threads request regions simultaneously from different size
   classes, the stash rarely goes above 1 entry.

I am not certain about the Windows impact of this change, as `sanitizer_win.cc`
has its own version of MmapAlignedOrDie, maybe someone could chime in on this.

MmapAlignedOrDie is effectively unused after this change and could be removed
at a later point. I didn't notice any sizeable performance gain, even though we
are saving a few `mmap`/`munmap` syscalls.

Reviewers: alekseyshl, kcc, dvyukov

Reviewed By: alekseyshl

Subscribers: llvm-commits, kubamracek

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

llvm-svn: 303879

Fix a test that was failing in C++11 mode introduced in r303874

llvm-svn: 303878

Clang-tidy doesn't understand -fno-ms-compatibility, so just removing 'not'

llvm-svn: 303877

Mark LWG#2900 as complete - we already do this, and I checked the tests in a couple days ago (r303268 & r303824)

llvm-svn: 303876

NewGVN: Fix PR 33119, PR 33129, due to regressed undef handling
Fix PR33120 and others by eliminating self-cycles a different way.

llvm-svn: 303875

Add support for shared_ptr<FunctionType>

Fixes PR27566.

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

llvm-svn: 303874

Don't defer to the GCC driver for linking arm-baremetal

Also comes with a cmake cache for building the runtime bits:

 $ cmake <normal cmake flags> \
   -DBAREMETAL_ARMV6M_SYSROOT=/path/to/sysroot \
   -DBAREMETAL_ARMV7M_SYSROOT=/path/to/sysroot \
   -DBAREMETAL_ARMV7EM_SYSROOT=/path/to/sysroot \
   -C /path/to/clang/cmake/caches/BaremetalARM.cmake \
   /path/to/llvm

https://reviews.llvm.org/D33259

llvm-svn: 303873