We need to include StringRef.h.

Pick up all the Pass headers in the root for MSVC projects

Pick up the DWARFLinker headers in MSVC projects

Pick up the CodeGen/MIRParser headers in MSVC projects

Pick up the GlobalISel headers in MSVC projects

Copy + paste typo meant we were picking up the include/llvm/Analysis path instead

Correctly pick up the OMP*.h headers in MSVC projects

This reverts commit b8d08e96.

This change causes a 1% compile-time and 1% memory usage regression:

http://llvm-compile-time-tracker.com/compare.php?from=73b7dd1fb3c17a4ac4b1f1e603f26fa708009649&to=b8d08e961df1d229872c785ebdbc8367432e9752&stat=instructions
http://llvm-compile-time-tracker.com/compare.php?from=73b7dd1fb3c17a4ac4b1f1e603f26fa708009649&to=b8d08e961df1d229872c785ebdbc8367432e9752&stat=max-rss

Cost-modeling decisions are tied to the compute interleave groups
(widening decisions, scalar and uniform values). When invalidating the
interleave groups, those decisions also need to be invalidated.

Otherwise there is a mis-match during VPlan construction.
VPWidenMemoryRecipes created initially are left around w/o converting them
into VPInterleave recipes. Such a conversion indeed should not take place,
and these gather/scatter recipes may in fact be right. The crux is leaving around
obsolete CM_Interleave (and dependent) markings of instructions along with
their costs, instead of recalculating decisions, costs, and recipes.

Alternatively to forcing a complete recompute later on, we could try
to selectively invalidate the decisions connected to the interleave
groups. But we would likely need to run the uniform/scalar value
detection parts again anyways and the extra complexity is probably not
worth it.

Fixes PR45572.

Reviewers: gilr, rengolin, Ayal, hsaito

Reviewed By: Ayal

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

This is a regression since:
  [lldb][NFC] Modernize lang/cpp/scope test
  acb0b99c
  rGacb0b99c

  File "/home/jkratoch/redhat/llvm-monorepo/lldb/test/API/lang/cpp/scope/TestCppScope.py", line 19, in test
    self.assertEqual(global_var_names, expected_var_names)
  AssertionError: Lists differ: ['C::a', 'A::a', 'B::a', '::a'... != ['A::a', 'B::a', 'C::a', '::a'...
  First differing element 0:
  C::a
  A::a
  - ['C::a', 'A::a', 'B::a', '::a']
  + ['A::a', 'B::a', 'C::a', '::a']

ManualDWARFIndex using NameToDIE does not sort alphabetically:
    // This is only for uniqueness, not lexicographical ordering, so we can
    // just compare pointers.
    return uintptr_t(lhs.GetCString()) < uintptr_t(rhs.GetCString());

Cherrypick the upstream fix commit a77d5f7 onto llvm/utils/benchmark
and libcxx/utils/google-benchmark.
This fixes LLVM's 32-bit RISC-V compilation, and the issues
mentioned in https://github.com/google/benchmark/pull/955
An additional cherrypick of ecc1685 fixes some minor formatting
issues introduced by the preceding commit.

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

Summary:
 C874, C875, C878, C880 and C881 checks are implemented.

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

Summary:
The instruction in non-text section can not be executed, so they will not affect performance.
In addition, their encoding values are treated as data, so we should not touch them.

Reviewers: MaskRay, reames, LuoYuanke, jyknight

Reviewed By: MaskRay

Subscribers: annita.zhang, hiraditya, llvm-commits

Tags: #llvm

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

Since D77214 there is a testsuite regression for TestFixIts.py
on Fedora 31 x86_64.
    File "/home/jkratoch/redhat/llvm-monorepo/lldb/test/API/commands/expression/fixits/TestFixIts.py", line 148, in test_with_target
      self.assertEquals(value.GetError().GetCString(), "error: No value")
  AssertionError: 'error: error: Multiple internal symbols found for \'d\'\nid = {0x00000d2a}, ran [truncated]... != 'error: No value'

That is because Fedora glibc incl. libm.so contains also ELF debug
symbols and there exists a 'd' symbol:
  (gdb) p d
  $1 = {i = {0, 1076887552}, d = 16}
  (gdb) p &d
  $2 = (const number *) 0x7ffff78e8bc0 <d>
  (gdb) info sym 0x7ffff78e8bc0
  d in section .rodata of /lib64/libm.so.6

  $ nm /lib64/libm.so.6 |grep ' d$'
  00000000000bfbc0 r d
  00000000000caa20 r d
  00000000000caa20 r d
  00000000000caa20 r d

  glibc-build$ for i in `find -name "*.o"`;do nm 2>/dev/null $i|grep ' d$' && echo $i;done
  0000000000000080 r d
  ./math/s_atan-fma4.o
  0000000000000080 r d
  ./math/s_atan-avx.o
  0000000000000080 r d
  ./math/s_atan.o

This variable is being used, but it's not being set (it's only set
for ubsan_minimal, but not ubsan). This addresses a regression that
was introduced in D78325.

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

whether they have missing header files.

Whether a module's headers happen to be present on the local file system
should make no difference to whether we make its contents visible when
importing another module that re-exports it. If we have an up-to-date
AST file that we can load, that's all that matters.

This fixes the ability to header syntax checking for modular headers in
C++20 mode (or in prior modes where -fmodules-local-submodule-visibility
is enabled but -fmodules is not).

modules too.

This more accurately reflects the semantics of this flag, as distinct
from "IsAvailable", which (in an explicit modules world) only describes
whether a module is buildable, not whether it's importable.

Summary:
This flag has been deprecated, with an on-by-default warning encouraging
users to explicitly specify whether they mean "all" or ubsan for 5 years
(released in Clang 3.7). Change it to mean what we wanted and
undeprecate it.

Also make the argument to -fsanitize-trap optional, and likewise default
it to 'all', and express the aliases for these flags in the .td file
rather than in code. (Plus documentation updates for the above.)

Reviewers: kcc

Subscribers: cfe-commits

Tags: #clang

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

[MachineOutliner] fix test for excluding CFI and add test to include CFI in outlining

New test to check that we only outline CFI instruction if all CFI
Instructions in the function would be captured by the outlining

adding x86 tests analagous to AARCH64 cfi tests

Revision: https://reviews.llvm.org/D77852

BitVectors and SmallBitVectors with equal contents but different
capacities were getting different hashes.

Reviewed By: aganea

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

[X86] Clean up some mir tests with INLINEASM to avoid regdef or to correct the immediate for the regdef.

The immediate used for the regdef is the encoding for the register
class in the enum generated by tablegen. This encoding will change
any time a new register class is added. Since the number is part
of the input, this means it can become stale.

This change modifies some test to avoid this kind of immediate
all together. And updates one test to use the current encoding of
GR64.

Summary:
The tests referred to in Chapter 3 of the tutorial were missing from the tutorial test
directory; this adds those missing tests. This also cleans up some stale directory paths and code
snippets used throughout the tutorial.

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

Summary:
The tests referred to in Chapter 3 of the tutorial were missing from the tutorial test
directory; this adds those missing tests. This also cleans up some stale directory paths and code
snippets used throughout the tutorial.

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

Summary:
The tests referred to in Chapter 3 of the tutorial were missing from the tutorial test
directory; this adds those missing tests. This also cleans up some stale directory paths and code
snippets used throughout the tutorial.

Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, aartbik, liufengdb, Joonsoo, llvm-commits

Tags: #llvm

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

Reviewers: craig.topper, dblaikie

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

Introduce a function __scudo_get_error_info() that may be called to interpret
a crash resulting from a memory error, potentially in another process,
given information extracted from the crashing process. The crash may be
interpreted as a use-after-free, buffer overflow or buffer underflow.

Also introduce a feature to optionally record a stack trace for each
allocation and deallocation. If this feature is enabled, a stack trace for
the allocation and (if applicable) the deallocation will also be available
via __scudo_get_error_info().

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

Use the unique filenames that are used when /lldsavetemps is passed.
After this change, module names for LTO blobs in PDBs will be unique.
Visual Studio and probably other debuggers expect module names to be
unique.

Revert some changes from 1e0b158d (2017) that are no longer necessary
after removing MSVC LTO support.

Reviewed By: MaskRay

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

[AbstractCallSite] Fix some doxygen comments I failed to update when ImmutableCallSite was replaced with CallBase.

Also fix an 80 column violation.

Directly select from the intrinsic. This wasn't getting much value
from the custom node.

According to Nathaniel McVicar on the review for D73967,
SematTemplateDeduction hit the 16 bit COFF limit.  This adds it to the
/bigobj list.

SmallVector currently uses 32bit integers for size and capacity to reduce
sizeof(SmallVector). This limits the number of elements to UINT32_MAX.

For a SmallVector<char>, this limits the SmallVector size to only 4GB.
Buffering bitcode output uses SmallVector<char>, but needs >4GB output.

This changes SmallVector size and capacity to conditionally use word-size
integers if the element type is small (<4 bytes). For larger elements types,
the vector size can reach ~16GB with 32bit size.

Making this conditional on the element type provides both the smaller
sizeof(SmallVector) for larger types which are unlikely to grow so large,
and supports larger capacities for smaller element types.

This change also includes a fix for the bug where a SmallVector with 32bit
size has reached UINT32_MAX elements, and cannot provide guaranteed growth.

Context:

    // Double the size of the allocated memory, guaranteeing space for at
    // least one more element or MinSize if specified.
    void grow(size_t MinSize = 0) { this->grow_pod(MinSize, sizeof(T)); }

    void push_back(const T &Elt) {
      if (LLVM_UNLIKELY(this->size() >= this->capacity()))
        this->grow();
      memcpy(reinterpret_cast<void *>(this->end()), &Elt, sizeof(T));
      this->set_size(this->size() + 1);
    }

When grow is called in push_back() without a MinSize specified, this is
relying on the guarantee of space for at least one more element.

There is an edge case bug where the SmallVector is already at its maximum size
and push_back() calls grow() with default MinSize of zero. Grow is unable to
provide space for one more element, but push_back() assumes the additional
element it will be available. This can result in silent memory corruption, as
this->end() will be an invalid pointer and the program may continue executing.

An alternative to this fix would be to remove the default argument from
grow(), which would mean several changing grow() to grow(this->size()+1)
in several places.

No test case added because it would require allocating a large ammount.

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

Starting with hasRedZone adding MachineFunctionInfo to be put in the YAML for MIR files.

Split out of: D78062

Based on implementation for MachineFunctionInfo for WebAssembly

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

Patch by Andrew Litteken! (AndrewLitteken)

Summary:
Due to sandbox restrictions in the recent versions of the simulator runtime the
atos program is no longer able to access the task port of a parent process
without additional help.

This patch fixes this by registering a task port for the parent process
before spawning atos and also tells atos to look for this by setting
a special environment variable.

This patch is based on an Apple internal fix (rdar://problem/43693565) that
unfortunately contained a bug (rdar://problem/58789439) because it used
setenv() to set the special environment variable. This is not safe because in
certain circumstances this can trigger a call to realloc() which can fail
during symbolization leading to deadlock. A test case is included that captures
this problem.

The approach used to set the necessary environment variable is as
follows:

1. Calling `putenv()` early during process init (but late enough that
malloc/realloc works) to set a dummy value for the environment variable.

2. Just before `atos` is spawned the storage for the environment
variable is modified to contain the correct PID.

A flaw with this approach is that if the application messes with the
atos environment variable (i.e. unsets it or changes it) between the
time its set and the time we need it then symbolization will fail. We
will ignore this issue for now but a `DCHECK()` is included in the patch
that documents this assumption but doesn't check it at runtime to avoid
calling `getenv()`.

The issue reported in rdar://problem/58789439 manifested as a deadlock
during symbolization in the following situation:

1. Before TSan detects an issue something outside of the runtime calls
setenv() that sets a new environment variable that wasn't previously
set. This triggers a call to malloc() to allocate a new environment
array. This uses TSan's normal user-facing allocator. LibC stores this
pointer for future use later.

2. TSan detects an issue and tries to launch the symbolizer. When we are in the
symbolizer we switch to a different (internal allocator) and then we call
setenv() to set a new environment variable. When this happen setenv() sees
that it needs to make the environment array larger and calls realloc() on the
existing enviroment array because it remembers that it previously allocated
memory for it. Calling realloc() fails here because it is being called on a
pointer its never seen before.

The included test case closely reproduces the originally reported
problem but it doesn't replicate the `((kBlockMagic)) ==
((((u64*)addr)[0])` assertion failure exactly. This is due to the way
TSan's normal allocator allocates the environment array the first time
it is allocated. In the test program addr[0] accesses an inaccessible
page and raises SIGBUS. If TSan's SIGBUS signal handler is active, the
signal is caught and symbolication is attempted again which results in
deadlock.

In the originally reported problem the pointer is successfully derefenced but
then the assert fails due to the provided pointer not coming from the active
allocator. When the assert fails TSan tries to symbolicate the stacktrace while
already being in the middle of symbolication which results in deadlock.

rdar://problem/58789439

Reviewers: kubamracek, yln

Subscribers: jfb, #sanitizers, llvm-commits

Tags: #sanitizers

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

Fix buildbot failures due to ef49b1d9
(which was a revert of a previous change).

We should only modify existing ones. Previously, we were creating
MachineFunctions for externally-available functions. AFAICT this was benign
in tree but ultimately led to asan bugs in our out of tree target.

This reverts commit 1d0f7579 because of
https://bugs.llvm.org/show_bug.cgi?id=45590. Needs investigation.