[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

Disable MSVC-Compat mode for two tests that use C++Operator Names

MSVC doesn't support C++ operator names (using 'or' instead of ||,
'not' instead of '!', etc), so this was disabled in MSVC mode in r303798.
This fixes the regression noticed on the buildbots.

llvm-svn: 303872

Make git-clang-format python 3 compatible

Summary: This patch attempts to make `git-clang-format` both python2 and python3 compatible. Currently it only works in python2.

Reviewers: modocache, compnerd, djasper, jbcoe, srhines, ddunbar

Reviewed By: jbcoe

Subscribers: kimgr, mgorny, llvm-commits, cfe-commits

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

llvm-svn: 303871

[InstCombine] Teach isAllocSiteRemovable to look through addrspacecasts

Reviewed By: reames

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

llvm-svn: 303870

[sanitizer] Pair atomic acquire with release in BlockingMutex::Unlock

Summary:
Dmitry, seeking your expertise. I believe, the proper way to implement
Lock/Unlock here would be to use acquire/release semantics. Am I missing
something?

Reviewers: dvyukov

Subscribers: llvm-commits, kubamracek

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

llvm-svn: 303869

[coroutines] Diagnose when promise types fail to declare either return_void or return_value.

Summary:
According to the PDTS it's perfectly legal to have a promise type that defines neither `return_value` nor `return_void`. However a coroutine that uses such a promise type will almost always have UB, because it can never `co_return`.

This patch changes Clang to diagnose such cases as an error. It also cleans up some of the diagnostic messages relating to member lookup in the promise type.

Reviewers: GorNishanov, rsmith

Reviewed By: GorNishanov

Subscribers: cfe-commits

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

llvm-svn: 303868

[coroutines] Bump __cpp_coroutines version

Summary: This patch is needed so that Libc++ can actually tess if Clang supports coroutines, instead of just paying lip service with a partial implementation. Otherwise the libc++ test suite will fail against older versions of Clang

Reviewers: GorNishanov, rsmith

Reviewed By: GorNishanov

Subscribers: cfe-commits

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

llvm-svn: 303867

Add generic __bswap[ds]i2 implementations

Summary:
In FreeBSD we needed to add generic implementations for `__bswapdi2` and
`__bswapsi2`, since gcc 6.x for mips is emitting calls to these.  See:

https://reviews.freebsd.org/D10838 and https://reviews.freebsd.org/rS318601

The actual mips code generated for these generic C versions is pretty
OK, as can be seen in the (FreeBSD) review.

I checked over gcc sources, and it seems that it can emit these calls on
more architectures, so maybe it's best to simply always add them to the
compiler-rt builtins library.

Reviewers: howard.hinnant, compnerd, petarj, emaste

Reviewed By: compnerd, emaste

Subscribers: mgorny, llvm-commits, arichardson

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

llvm-svn: 303866

[cmake] Disable building emutls.c for baremetal targets.

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

llvm-svn: 303865

[powerpc] deactivate flakey test halt_on_error-torture.cc on powerpc64 be

This test case occassionally fails when run on powerpc64 be.

asan/TestCases/Posix/halt_on_error-torture.cc

The failure causes false problem reports to be sent to developers whose
code had nothing to do with the failures.  Reactivate it when the real
problem is fixed.

This could also be related to the same problems as with the tests
ThreadedOneSizeMallocStressTest, ThreadedMallocStressTest, ManyThreadsTest,
and several others that do not run reliably on powerpc.

llvm-svn: 303864

[PowerPC] Fix test case sem_init_glibc.cc for powerpc64be

This test case fails on powerpc64be with older glibcs because of the glibc
version test.

llvm-svn: 303863

Last commit included some extra constexpr; remove them

llvm-svn: 303862

[AMDGPU] add __builtin_amdgcn_s_getpc

Summary: Added the builtin corresponding to the s_getpc intrinsic added in llvm D32862

Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye

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

llvm-svn: 303861

[InstCombine] make icmp-mul fold more efficient

There's probably a lot more like this (see also comments in D33338 about responsibility),
but I suspect we don't usually get a visible manifestation.

Given the recent interest in improving InstCombine efficiency, another potential micro-opt
that could be repeated several times in this function: morph the existing icmp pred/operands
instead of creating a new instruction.

llvm-svn: 303860

[AMDGPU] add intrinsic for s_getpc

Summary: The s_getpc instruction is exposed as intrinsic llvm.amdgcn.s.getpc.

Reviewers: arsenm

Reviewed By: arsenm

Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye

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

llvm-svn: 303859

[X86] Adding vpopcntd and vpopcntq instructions

AVX512_VPOPCNTDQ is a new feature set that was published by Intel.
The patch represents the LLVM side of the addition of two new intrinsic based instructions (vpopcntd and vpopcntq).

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

llvm-svn: 303858

[X86] Adding avx512_vpopcntdq feature set and its intrinsics

AVX512_VPOPCNTDQ is a new feature set that was published by Intel.
The patch represents the Clang side of the addition of six intrinsics for two new machine instructions (vpopcntd and vpopcntq).
It also includes the addition of the new feature set.

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

llvm-svn: 303857

Make for_each_n only avaliable on C++17

llvm-svn: 303856

[GVNSink] Pacify MSVC

Don't convert an unsigned to a pointer for a sentinel, use a size_t instead.

llvm-svn: 303855

Revert "Fix FDE indexing while scan debug_info section."

This reverts commit r303847 as it introduces a number of regressions.
Investigation has showed that we are parsing the CIE entries in the
debug_frame section incorrectly -- we are parsing them the same way as
eh_frame, but the entries in debug_frame have a couple of extra entries
which have not been taken into account.

llvm-svn: 303854

[GVNSink] Don't define operator<< in NDEBUG

Without debug macros enabled, the raw_ostream operator<< overload
is unused.

llvm-svn: 303852

[CodeGen] Pessimize aliasing for member unions (and may-alias) objects

Use the TBAA info of the omnipotent char for these objects.

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

llvm-svn: 303851

[GVNSink] GVNSink pass

This patch provides an initial prototype for a pass that sinks instructions based on GVN information, similar to GVNHoist. It is not yet ready for commiting but I've uploaded it to gather some initial thoughts.

This pass attempts to sink instructions into successors, reducing static
instruction count and enabling if-conversion.
We use a variant of global value numbering to decide what can be sunk.
Consider:

[ %a1 = add i32 %b, 1  ]   [ %c1 = add i32 %d, 1  ]
[ %a2 = xor i32 %a1, 1 ]   [ %c2 = xor i32 %c1, 1 ]
                 \           /
           [ %e = phi i32 %a2, %c2 ]
           [ add i32 %e, 4         ]

GVN would number %a1 and %c1 differently because they compute different
results - the VN of an instruction is a function of its opcode and the
transitive closure of its operands. This is the key property for hoisting
and CSE.

What we want when sinking however is for a numbering that is a function of
the *uses* of an instruction, which allows us to answer the question "if I
replace %a1 with %c1, will it contribute in an equivalent way to all
successive instructions?". The (new) PostValueTable class in GVN provides this
mapping.

This pass has some shown really impressive improvements especially for codesize already on internal benchmarks, so I have high hopes it can replace all the sinking logic in SimplifyCFG.

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

llvm-svn: 303850

(no commit message)

llvm-svn: 303849

Recommit "RunThreadPlan: Fix halting logic in IgnoreBreakpoints = false"

This is a resubmit of r303732, which was reverted due to a regression.

The original patch caused a regression in TestLoadUnload, which has only showed
up when running the remote test suite. The problem there was that we interrupted
the target just as it has hit the rendezvous breakpoint in the dlopen call. This
meant that the stop reason was set to "breakpoint" even though the event would
not have been broadcast if we had not stopped the process. I fix this by
checking StopInfo->ShouldNotify() before stopping.

I also add a new test for the handling of conditional breakpoints in
expressions, which I noticed to be broken (pr33164)

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

llvm-svn: 303848

Fix FDE indexing while scan debug_info section.

There are some differences between eh_frame and debug_frame formats that
are not considered by DWARFCallFrameInfo::GetFDEIndex. An FDE entry
contains CIE_pointer in debug_frame in same place as cie_id in eh_frame.
As described in dwarf standard (section 6.4.1), CIE_pointer is an
"offset into the .debug_frame section". So, variable cie_offset should
be equal cie_id for debug_frame.

FDE entries with zeroth CIE pointer (which is actually placed in cie_id
variable) shouldn't be ignored also.

I have also added a little change which allow to use debug_info section
when eh_frame is absent. This case really can take place on some platforms.

Patch from tatyana-krasnukha.
https://reviews.llvm.org/D33504

llvm-svn: 303847

[OpenCL] reserve_id_t cannot be used as argument to kernel function

Reviewers: Anastasia

Reviewed By: Anastasia

Subscribers: yaxunl, cfe-commits, bader

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

llvm-svn: 303846

[PM] Teach the PGO instrumentation pasess to run GlobalDCE before
instrumenting code.

This is important in the new pass manager. The old pass manager's
inliner has a small DCE routine embedded within it. The new pass manager
relies on the actual GlobalDCE pass for this.

Without this patch, instrumentation profiling with the new PM results in
massive code bloat in the object files because the instrumentation
itself ends up preventing DCE from working to remove the code.

We should probably change the instrumentation (and/or DCE) so that we
can eliminate dead code even if instrumented, but we shouldn't even
spend the time generating instrumentation for that code so this still
seems like a good patch.

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

llvm-svn: 303845

[OpenCL] Added regression test on invalid vector initialization.

Summary: This patch increases code coverage.

Reviewers: Anastasia

Reviewed By: Anastasia

Subscribers: cfe-commits, bader, yaxunl

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

llvm-svn: 303844

[PM/Unswitch] Fix a bug in the domtree update logic for the new unswitch
pass.

The original logic only considered direct successors of the hoisted
domtree nodes, but that isn't really enough. If there are other basic
blocks that are completely within the subtree, their successors could
just as easily be impacted by the hoisting.

The more I think about it, the more I think the correct update here is
to hoist every block on the dominance frontier which has an idom in the
chain we hoist across. However, this is subtle enough that I'd
definitely appreciate some more eyes on it.

Sadly, if this is the correct algorithm, it requires computing a (highly
localized) dominance frontier. I've done this in the simplest (IE, least
code) way I could come up with, but that may be too naive. Suggestions
welcome here, dominance update algorithms are not an area I've studied
much, so I don't have strong opinions.

In good news, with this patch, turning on simple unswitch passes the
LLVM test suite for me with asserts enabled.

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

llvm-svn: 303843

[compiler-rt] Change default of allow_user_segv_handler to true

Reviewers: eugenis

Subscribers: srhines, kubamracek, llvm-commits

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

llvm-svn: 303842

[MVT] Fix the identation of the start of the MVT class. NFC

llvm-svn: 303841

[SelectionDAG] Fix off by one in a compare in getOperationAction.

If Op is equal to array_lengthof, the lookup would be out of bounds, but we were only checking for greater than. I suspect nothing ever passes in the equal value because its a sentinel to mark the end of the builtin opcodes and not a real opcode.

So really this fix is just so that the code looks right and makes sense.

llvm-svn: 303840

Drop newline in docs builder to see if Polly docs are updated

llvm-svn: 303839

Remove <experimental/coroutine> from the module map for now. It doesn't work unless modules are enabled

llvm-svn: 303838

Disable the coroutines tests until Clang bumps __cpp_coroutines to reflect recent changes

llvm-svn: 303837

Add <experimental/coroutine>

This patch adds the library portions of the coroutines PDTS,
which should now be supported by Clang.

llvm-svn: 303836

Fix broken links on C++1z status page

llvm-svn: 303835

[LegacyPM] Make the 'addLoop' method accept a loop to add rather than
having it internally allocate the loop.

This is a much more flexible API and necessary in the new loop unswitch
to reasonably support both new and old PMs in common code. It also just
seems like a cleaner separation of concerns.

NFC, this should just be a pure refactoring.

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

llvm-svn: 303834

Add non-parallel version of for_each_n (+tests) from the Parallelism TS

llvm-svn: 303833

Fix the warning when you pass -c to step/next/si/ni.

During some cleanup the test for whether the thread plan
accepted an iteration count was reversed, so we give a
warning when it will actually work, and don't when it won't.

<rdar://problem/32379280>

llvm-svn: 303832

[coroutines] Fix fallthrough diagnostics for coroutines

Summary:
This patch fixes a number of issues with the analysis warnings emitted when a coroutine may reach the end of the function w/o returning.

* Fix bug where coroutines with `return_value` are incorrectly diagnosed as missing `co_return`'s.
* Rework diagnostic message to no longer say "non-void coroutine", because that implies the coroutine doesn't have a void return type, which it might. In this case a non-void coroutine is one who's promise type does not contain `return_void()`

As a side-effect of this patch, coroutine bodies that contain an invalid coroutine promise objects are marked as invalid.

Reviewers: GorNishanov, rsmith, aaron.ballman, majnemer

Reviewed By: GorNishanov

Subscribers: cfe-commits

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

llvm-svn: 303831

Fixed nondeterminism in RuleMatcher::emit.

llvm-svn: 303829

[libFuzzer] Don't replace custom signal handlers.

Summary:
This allows to keep handlers installed by sanitizers.
In other cases third-party code can replace handlers after libFuzzer
initialization anyway.

Reviewers: kcc

Subscribers: llvm-commits

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

llvm-svn: 303828

Fix coverage check for full post-dominator basic blocks.

Coverage instrumentation which does not instrument full post-dominators
and full-dominators may skip valid paths, as the reasoning for skipping
blocks may become circular.
This patch fixes that, by only skipping
full post-dominators with multiple predecessors, as such predecessors by
definition can not be full-dominators.

llvm-svn: 303827

[coroutines] CoroFrame.cpp conform to coding convention (s/repeat/Repeat) (NFC)

llvm-svn: 303826

[coroutines] Relocate instructions that maybe spilled after coro.begin

Summary:
Frontend generates store instructions after allocas, for example:

```
define i8* @f(i64 %this) "coroutine.presplit"="1" personality i32 0 {
entry:
  %this.addr = alloca i64
  store i64 %this, i64* %this.addr
  ..
  %hdl = call i8* @llvm.coro.begin(token %id, i8* %alloc)

```
Such instructions may require spilling into coro.frame, but, coro-frame address is only available after coro.begin and thus needs to be moved after coro.begin.
The only instructions that should not be moved are the arguments of coro.begin and all of their operands.

Reviewers: GorNishanov, majnemer

Reviewed By: GorNishanov

Subscribers: llvm-commits, EricWF

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

llvm-svn: 303825

Add some constexpr tests for optional's move/copy ctor

llvm-svn: 303824

Correct compiler warnings and Debug build of the NetBSD target

Correct files present only in the NetBSD build.

llvm-svn: 303823

[PowerPC] Fix a performance bug for PPC::XXSLDWI.

There are some VectorShuffle Nodes in SDAG which can be selected to XXSLDWI
instruction, this patch recognizes them and does the selection to improve the
PPC performance.

llvm-svn: 303822

Print symbols from COFF import libraries.

This change allows llvm-nm to print symbols found in import libraries,
in part by allowing COFFImportFiles to be casted to SymbolicFiles.

Patch by Dave Lee!

llvm-svn: 303821

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

llvm-svn: 303820

[coroutines] Allow rematerialization upto 4 times. Remove incorrect assert

Reviewers: majnemer

Subscribers: EricWF, llvm-commits

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

llvm-svn: 303819