Reviewers: dschuff

Reviewed By: dschuff

Subscribers: hiraditya, aheejin, llvm-commits

Tags: #llvm

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

During extraction, stale llvm.assume handles may be retained in the
original function. The setup is:

1) CodeExtractor unregisters assumptions in the blocks that are to be
   extracted.

2) Extraction happens. There are now two functions: f1 and f1.extracted.

3) Leftover assumptions in f1 (/not/ removed as they were not in the set of
   blocks to be extracted) now have affected-value llvm.assume handles in
   f1.extracted.

When assumptions for a value used in f1 are looked up, ValueTracking can assert
as some of the handles are in the wrong function. To fix this, simply erase the
llvm.assume calls in the extracted function.

Alternatives include flushing the assumption cache in the original function, or
walking all values used in the original function to prune stale affected-value
handles. Both seem more expensive.

Testing: check-llvm, LNT run with -mllvm -hot-cold-split enabled

rdar://58460728

The copy assignment operator is supposed to return the class and not
void. Fix the methods and the reproducer instrumentation macros.

I've hit this stack trace a few times but don't have a good reproducer.
The code is unsafe by inspection, though.

2 fixes:

Register coloring can re-assign virtual registers. When the frame base register
is colored, update the DwarfFrameBase accordingly When the frame base register
is stackified, do not attempt to encode DW_AT_frame_base as a local In the
future we will presumably want to handle this case better but for now we can
emit worse debug info rather than crashing.

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

Currently the constructor is compiler generated which means it doesn't
get instrumented for the reproducers.

Currently the constructor is compiler generated which means it doesn't
get instrumented for the reproducers.

In commit 5eaf44f9 I removed the last
instance of TypeSystemClang from ValueObject, so the header is no longer
needed.

Previously, the enums didn't account for all the possible cases, which
could cause misleading results (particularly for a "switch" on
FunctionModRefBehavior).

Fixes regression in polly from recent patch to add writeonly to memset.

While I'm here, also fix a few dubious uses of the FMRB_* enum values.

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

Summary:
Ninja is no longer an experimental tool, documentation changed to
reflect this.

Reviewers: nikola

Reviewed By: nikola

Subscribers: cfe-commits

Tags: #clang

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

Fixes error: unknown type name 'nullptr_t'; did you mean
'std::nullptr_t'.

Include the return value in the recording log statements. This helps
diagnose uninstrumented (copy assignment) constructors.

This has the same behavior as converting std::string_view to
std::string. This is an expensive conversion, so explicit conversions
are helpful for avoiding unneccessary string copies.

libc++ on Android needs to be linked against libandroid_support on API
levels less than 21 to provide needed functions that aren't in the libc
on those platforms (e.g. posix_memalign for libcxxabi). libc++ from the
NDK is a linker script that pulls in libandroid_support, but for
building libc++ itself, we need to explicitly add libandroid_support as
a dependency. Moreover, libc++ headers reference the functions provided
by libandroid_support, so it needs to be added as a public dependency.

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

mlockall and munlockall were introduced in Android API 17, so avoid
referencing them on prior versions.

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