Summary:
Due to Unity, we had to reduce our region sizes, but in some rare
situations, some programs (mostly tests AFAICT) manage to fill up
a region for a given size class.

So this adds a workaround for that attempts to allocate the block
from the immediately larger size class, wasting some memory but
allowing the application to keep going.

Reviewers: pcc, eugenis, cferris, hctim, morehouse

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

This extract common code between the 4 TBD formats in a header that can
be shared.

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

Same as D73328 but for TBD_V4. One notable tidbit is that the swift abi
version for swift 1 & 2 is emitted as a float which is considered
invalid input.

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

Looks like on some system, version is printed on stderr, on some it's on stdout...

Summary:
Recursion is a powerful tool, but like any tool
without care it can be dangerous. For example,
if the recursion is unbounded, you will
eventually run out of stack and crash.

You can of course track the recursion depth
but if it is hardcoded, there can always be some
other environment when that depth is too large,
so said magic number would need to be env-dependent.
But then your program's behavior is suddenly more env-dependent.

Also, recursion, while it does not outright stop optimization,
recursive calls are less great than normal calls,
for example they hinder inlining.

Recursion is banned in some coding guidelines:
* SEI CERT DCL56-CPP. Avoid cycles during initialization of static objects
* JPL 2.4 Do not use direct or indirect recursion.
* I'd say it is frowned upon in LLVM, although not banned
And is plain unsupported in some cases:
* OpenCL 1.2, 6.9 Restrictions: i. Recursion is not supported.

So there's clearly a lot of reasons why one might want to
avoid recursion, and replace it with worklist handling.
It would be great to have a enforcement for it though.

This implements such a check.
Here we detect both direct and indirect recursive calls,
although since clang-tidy (unlike clang static analyzer)
is CTU-unaware, if the recursion transcends a single standalone TU,
we will naturally not find it :/

The algorithm is pretty straight-forward:
1. Build call-graph for the entire TU.
   For that, the existing `clang::CallGraph` is re-used,
   although it had to be modified to also track the location of the call.
2. Then, the hard problem: how do we detect recursion?
   Since we have a graph, let's just do the sane thing,
   and look for Strongly Connected Function Declarations - widely known as `SCC`.
   For that LLVM provides `llvm::scc_iterator`,
   which is internally an Tarjan's DFS algorithm, and is used throught LLVM,
   so this should be as performant as possible.
3. Now that we've got SCC's, we discard those that don't contain loops.
   Note that there may be more than one loop in SCC!
4. For each loopy SCC, we call out each function, and print a single example
   call graph that shows recursion -- it didn't seem worthwhile enumerating
   every possible loop in SCC, although i suppose it could be implemented.
   * To come up with that call graph cycle example, we start at first SCC node,
     see which callee of the node is within SCC (and is thus known to be in cycle),
     and recurse into it until we hit the callee that is already in call stack.

Reviewers: JonasToth, aaron.ballman, ffrankies, Eugene.Zelenko, erichkeane, NoQ

Reviewed By: aaron.ballman

Subscribers: Charusso, Naghasan, bader, riccibruno, mgorny, Anastasia, xazax.hun, cfe-commits

Tags: #llvm, #clang

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

Summary:
Storing not just the callee, but the actual call may be interesting for some use-cases.
In particular, D72362 would like that to better pretty-print the cycles in call graph.

Reviewers: NoQ, erichkeane

Reviewed By: NoQ

Subscribers: martong, Charusso, cfe-commits

Tags: #clang

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

There's no reason why we should require a directory when asking for the version.

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

This is required to be legal. I'm not sure how we were getting away
without defining any rules for it.

These should always be passed by value

This allow it to recognize more loads as being consecutive when the load's address are complex at the start.

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

patch, NFC.

This reverts commit bb310b3f. This
breaks the stage2 ASan build, see:

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

rdar://59431448

When running on Windows under the following locale:

D:\llvm-project>python
Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getlocale()
('French_Canada', '1252')

This patch fixes the following issue:

# command stderr:
Traceback (most recent call last):
  File "D:/llvm-project/clang-tools-extra/test/../test\clang-tidy\check_clang_tidy.py", line 249, in <module>
    main()
  File "D:/llvm-project/clang-tools-extra/test/../test\clang-tidy\check_clang_tidy.py", line 245, in main
    run_test_once(args, extra_args)
  File "D:/llvm-project/clang-tools-extra/test/../test\clang-tidy\check_clang_tidy.py", line 162, in run_test_once
    diff_output.decode() +
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe0 in position 2050: invalid continuation byte
This is caused by diff reporting no EOL on the last line, and unfortunately this is written in French with accentuation on my locale.

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

Fix buildbots that create shared libraries from GSYM library by adding a dependency on LLVMDebugInfoDWARF.

Summary: This patch adds a convenience template function so we don't need to cast all types to `long` manually when calling `__llvm_libc::syscall`.

Reviewers: sivachandra, MaskRay, gchatelet

Reviewed By: sivachandra

Subscribers: libc-commits, tschuett

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

Original commit:
https://reviews.llvm.org/rG7683a084de6bd2637f2351f53389df8b610566cf

Implement a pass to convert gpu.launch_func op into a sequence of
Vulkan runtime calls. The Vulkan runtime API surface is huge so currently we
don't expose separate external functions in IR for each of them, instead we
expose a few external functions to wrapper libraries which manages
Vulkan runtime.

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

Reviewers: sivachandra

Reviewed By: sivachandra

Subscribers: MaskRay, tschuett, libc-commits

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

Summary:
The DWARF transformer is added as a class so it can be unit tested fully.

The DWARF is converted to GSYM format and handles many special cases for functions:
- omit functions in compile units with 4 byte addresses whose address is UINT32_MAX (dead stripped)
- omit functions in compile units with 8 byte addresses whose address is UINT64_MAX (dead stripped)
- omit any functions whose high PC is <= low PC (dead stripped)
- StringTable builder doesn't copy strings, so we need to make backing copies of strings but only when needed. Many strings come from sections in object files and won't need to have backing copies, but some do.
- When a function doesn't have a mangled name, store the fully qualified name by creating a string by traversing the parent decl context DIEs and then. If we don't do this, we end up having cases where some function might appear in the GSYM as "erase" instead of "std::vector<int>::erase".
- omit any functions whose address isn't in the optional TextRanges member variable of DwarfTransformer. This allows object file to register address ranges that are known valid code ranges and can help omit functions that should have been dead stripped, but just had their low PC values set to zero. In this case we have many functions that all appear at address zero and can omit these functions by making sure they fall into good address ranges on the object file. Many compilers do this when the DWARF has a DW_AT_low_pc with a DW_FORM_addr, and a DW_AT_high_pc with a DW_FORM_data4 as the offset from the low PC. In this case the linker can't write the same address to both the high and low PC since there is only a relocation for the DW_AT_low_pc, so many linkers tend to just zero it out.

Reviewers: aprantl, dblaikie, probinson

Subscribers: mgorny, hiraditya, llvm-commits

Tags: #llvm

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

DynTypedNode and ASTNodeKind are implemented as part of the clang AST
library, which uses the main clang namespace. There doesn't seem to be a
need for this extra level of namespacing.

I left behind aliases in the ast_type_traits namespace for out of tree
clients of these APIs. To provide aliases for the enumerators, I used
this pattern:
  namespace ast_type_traits {
  constexpr TraversalKind TK_AsIs = ::clang::TK_AsIs;
  }
I think the typedefs will be useful for migration, but we might be able
to drop these enumerator aliases.

Reviewed By: aaron.ballman

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

According to OpenMP 5.0, hint clause is alowed to be used in atomic
directives.

This reverts commit 80a34ae3 with fixes.

Previously, since bots turning on EXPENSIVE_CHECKS are essentially turning on
MachineVerifierPass by default on X86 and the fact that
inline-asm-avx-v-constraint-32bit.ll and inline-asm-avx512vl-v-constraint-32bit.ll
are not expected to generate functioning machine code, this would go
down to `report_fatal_error` in MachineVerifierPass. Here passing
`-verify-machineinstrs=0` to make the intent explicit.

This reverts commit bb51d243.

This reverts commit 80a34ae3 with fixes.

On bots llvm-clang-x86_64-expensive-checks-ubuntu and
llvm-clang-x86_64-expensive-checks-debian only,
llc returns 0 for these two tests unexpectedly. I tweaked the RUN line a little
bit in the hope that LIT is the culprit since this change is not in the
codepath these tests are testing.
llvm\test\CodeGen\X86\inline-asm-avx-v-constraint-32bit.ll
llvm\test\CodeGen\X86\inline-asm-avx512vl-v-constraint-32bit.ll

Summary:
This patch fixes logging to log incoming packets which was removed during a refactor.

We also enable logging to a "vscode.txt" file for each lldb-vscode test by creating the log file in the build artifacts directory for each test. This allows users to see the packets for their tests if needed and the log file is in a directory that will be removed after tests have been run.

Reviewers: labath, aadsm, serhiy.redko, jankratochvil, xiaobai, wallace

Subscribers: lldb-commits

Tags: #lldb

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

MemorySSA is often taking up an unreasonable fraction of runtime in
assertion enabled builds. Turns out that there is one code-path that
runs verifyMemorySSA() even if VerifyMemorySSA is not enabled. This
patch makes it conditional as well.

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

Also greatly improve i64 lowering. LegalizeIntegerTypes does the
correct narrowing if i64 isn't legal. Just workaround this for
SelectionDAG by making i64 legal and splitting in the patterns.

From the context, it looks like the test should not be run with `check-all`,
but it does. It turns out option argument resolving to True/False which
could not be passed down as is. There is one such example in
AddLLVM.cmake.

This tests works on Darwin. I will need to check windows and linux.