* Merge QueueLock and CompletionLock.
* Avoid spurious CompletionCondition.notify_all() when ActiveThreads is greater than 0.
* Use default member initializers.

Reviewed By: mehdi_amini

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

[ELF][PPC64] Don't perform toc-indirect to toc-relative relaxation for R_PPC64_TOC16_HA not followed by R_PPC64_TOC16_LO_DS

The current implementation assumes that R_PPC64_TOC16_HA is always followed
by R_PPC64_TOC16_LO_DS. This can break with:

// Load the address of the TOC entry, instead of the value stored at that address
  addis 3, 2, .LC0@tloc@ha  # R_PPC64_TOC16_HA
  addi  3, 3, .LC0@tloc@l   # R_PPC64_TOC16_LO
  blr

which is used by boringssl's util/fipstools/delocate/delocate.go
https://github.com/google/boringssl/blob/master/crypto/fipsmodule/FIPS.md has some documentation.
In short, this tool converts an assembly file to avoid any potential relocations.
The distance to an input .toc is not a constant after linking, so the assembly cannot use an `addis;ld` pair.
Instead, delocate changes the code to jump to a stub (`addis;addi`) which loads the TOC entry address.

Reviewed By: sfertile

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

Implement passing of ByVal formal arguments when the argument is passed
partly in the argument registers, with the remainder of the argument
passed on the stack.

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

Prior to this change, for a few compiler-rt libraries such as ubsan and
the profile library, Clang would embed "-defaultlib:path/to/rt-arch.lib"
into the .drective section of every object compiled with
-finstr-profile-generate or -fsanitize=ubsan as appropriate.

These paths assume that the link step will run from the same working
directory as the compile step. There is also evidence that sometimes the
paths become absolute, such as when clang is run from a different drive
letter from the current working directory. This is fragile, and I'd like
to get away from having paths embedded in the object if possible. Long
ago it was suggested that we use this for ASan, and apparently I felt
the same way back then:
https://reviews.llvm.org/D4428#56536

This is also consistent with how all other autolinking usage works for
PS4, Mac, and Windows: they all use basenames, not paths.

To keep things working for people using the standard GCC driver
workflow, the driver now adds the resource directory to the linker
library search path when it calls the linker. This is enough to make
check-ubsan pass, and seems like a generally good thing.

Users that invoke the linker directly (most clang-cl users) will have to
add clang's resource library directory to their linker search path in
their build system. I'm not sure where I can document this. Ideally I'd
also do it in the MSBuild files, but I can't figure out where they go.
I'd like to start with this for now.

Reviewed By: hans

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

vXi1 types are legalized by promoting, but the narrow vectors
are legalized by widening. This results in some truncates turning
into any_extends.

Similar to code in `getAArch64Cmp` in AArch64ISelLowering.

When we get a compare against a constant, sometimes, that constant isn't valid
for selecting an immediate form.

However, sometimes, you can get a valid constant by adding 1 or subtracting 1,
and updating the condition code.

This implements the following transformations when valid:

- x slt c => x sle c - 1
- x sge c => x sgt c - 1
- x ult c => x ule c - 1
- x uge c => x ugt c - 1

- x sle c => x slt c + 1
- x sgt c => s sge c + 1
- x ule c => x ult c + 1
- x ugt c => s uge c + 1

Valid meaning the constant doesn't wrap around when we fudge it, and the result
gives us a compare which can be selected into an immediate form.

This also moves `getImmedFromMO` higher up in the file so we can use it.

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

This reverts commit a3d95a50.

Reverting due to UBSan failures:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/40817/steps/check-lld%20ubsan/logs/stdio

This reverts commit 9598778b.

Reverting due to UBSan failures:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/40817/steps/check-lld%20ubsan/logs/stdio

UBSan complains about a memcpy with a null pointer, so just skip the
memcpy call if the data is empty.

It seems that D74892 still hasn't fixed the issue on the bot. Currently
investigating the bot breakage and meanwhile (again) reverting this...

Summary:
Removes usage of VectorType::getNumElements identified by test located
at CodeGen/aarch64-sve-intrinsics/acle_sve_abs.c. Since the type is an
SVE predicate vector, it makes sense to specialize the code for scalable
vectors only.

Reviewers: rengolin, efriedma

Reviewed By: efriedma

Subscribers: tschuett, kristof.beyls, rkruppe, psnobl, cfe-commits

Tags: #clang

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

We should synchronize reading of VFSWriter's data with the rest of the methods.

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

This adds support for

X + SETAE --> sbb X, -1
X - SETAE --> adc X, -1

Fixes PR45700

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

These tests show some missed opportunities to use sbb/adc.

I've modified isTruncateFree to get an accurate cost for types that need to be split. I'm planning to look into fixing it for all vectors, but need more cost cleanups first.

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

This speeds up linking chrome.dll with PGO instrumentation by 13%
(154271ms -> 134033ms).

LLVM's Option library is very slow. In particular, it allocates at least
one large-ish heap object (Arg) for every argument. When PGO
instrumentation is enabled, all the __profd_* symbols are added to the
@llvm.used list, which compiles down to these /INCLUDE: directives. This
means we have O(#symbols) directives to parse in the section, so we end
up allocating an Arg for every function symbol in the object file. This
is unnecessary.

To address the issue and speed up the link, extend the fast path that we
already have for /EXPORT:, which has similar scaling issues.

I promise that I took a hard look at optimizing the Option library, but
its data structures are very general and would need a lot of cleanup. We
have accumulated lots of optional features (option groups, aliases,
multiple values) over the years, and these are now properties of every
parsed argume...

Some bots apparently don't have that package.

compiler-rt is built in a unified configuration on some of the builders
which requires that this is updated to follow the same pattern as LLVM.

We unconditionally compared the DW_AT_ranges offset to the length of the
.debug_ranges section. For DWARF5 we should look at the debug_rnglists
section instead.

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

PYTHON_EXECUTABLE changed to Python3_EXECUTABLE in the lit test suite.

Committing without review, since the gn build is currently broken. Going
forward, more gn build changes may be necessary to get gn to find Python
3 instead of Python 2.

Summary:
Generated Protobuf library has to be in CLANG_EXPORTS and should also be
installed appropriately. The easiest way to do that is via CMake's
add_clang_library. That unfortunately applies "one directory - one
clang_(library|tool)" policy so .proto files should be in a separate directory
and complicates the layout.

This setup works both in shared and static libs mode.

Resolves: https://github.com/clangd/clangd/issues/351

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

Run "bash myscript.sh". This will work if bash is on PATH, which it
probably is, since developers have to use git.

Reviewed By: scott.linder

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

Looks like this was just a copy & paste mistake from
getDependentSizedExtVectorType. rdar://60092165

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

Some intrinsics in vecintrin.h are currently implemented by
performing address arithmetic in __INTPTR_TYPE__ and converting
the result to some pointer type.  While this works correctly,
it leads to suboptimal code generation since many optimizers
cannot trace the provenance of the resulting pointers.

Fixed by using "char *" pointer arithmetic instead.

System headers should avoid using the "vector" and "bool" keywords
since those might be redefined by user code.  For example, using
<stdbool.h> before <vecintrin.h> will currently lead to compiler
errors.

Fixed by using the reserved "__vector" and "__bool" keywords
instead.  NFC otherwise.

Committed in error without approval https://reviews.llvm.org/D79000

This reverts commit 015bca3e.

Summary:
Allow brace wrapping in C# property accessors to be controlled by configuration options.

Add new tests and revert old test results for MS style to their old state (as intended).

`FormatStyle.BraceWrapping.AfterFunction = true;` will change automatic property formatting from

```
Type MyType { get; set }
```

to

```
Type MyType
{ get; set }
```

Reviewers: krasimir, MyDeveloperDay

Subscribers: cfe-commits

Tags: #clang-format, #clang

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

Reviewers: krasimir, MyDeveloperDay

Reviewed By: MyDeveloperDay

Subscribers: cfe-commits

Tags: #clang-format, #clang

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

[mlir][assemblyFormat] Fix bug when using AttrSizedOperandSegments trait with only non-buildable operand types

Summary:
When creating an operation with
* `AttrSizedOperandSegments` trait
* Variadic operands of only non-buildable types
* assemblyFormat to automatically generate the parser
the `builder` local variable is used, but never declared.
This adds a fix as well as a test for this case as existing ones use buildable types only.

Reviewers: rriddle, Kayjukh, grosser

Reviewed By: Kayjukh

Subscribers: mehdi_amini, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, llvm-commits

Tags: #mlir, #llvm

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

This is primarily motivated by the desire to move from Python2 to
Python3.  `PYTHON_EXECUTABLE` is ambiguous.  This explicitly identifies
the python interpreter in use.  Since the LLVM build seems to be able to
completed successfully with python3, use that across the build.  The old
path aliases `PYTHON_EXECUTABLE` to be treated as Python3.

In `InstCombiner::visitAdd()`, we have
```
  // A+B --> A|B iff A and B have no bits set in common.
  if (haveNoCommonBitsSet(LHS, RHS, DL, &AC, &I, &DT))
    return BinaryOperator::CreateOr(LHS, RHS);
```
so we should handle such `or`'s here, too.

When passing a value of a struct/union type from secure to non-secure
state (that is returning from a CMSE entry function or passing an
argument to CMSE-non-secure call), there is a potential sensitive
information leak via the padding bits in the structure. It is not
possible in the general case to ensure those bits are cleared by using
Standard C/C++.

This patch makes the compiler emit code to clear such padding
bits. Since type information is lost in LLVM IR, the code generation
is done by Clang.

For each interesting record type, we build a bitmask, in which all the
bits, corresponding to user declared members, are set. Values of
record types are returned by coercing them to an integer. After the
coercion, the coerced value is masked (with bitwise AND) and then
returned by the function. In a similar manner, values of record types
are passed as arguments by coercing them to an array of integers, and
the coerced values themselves are masked.

For union types, we effectively clear only bits, which aren't part of
any member, since we don't know which is the currently active one.
The compiler will issue a warning, whenever a union is passed to
non-secure state.

Values of half-precision floating-point types are passed in the least
significant bits of a 32-bit register (GPR or FPR) with the most
significant bits unspecified. Since this is also a potential leak of
sensitive information, this patch also clears those unspecified bits.

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

Add support for reserving LR in:

* the driver through `-ffixed-x30`
* cc1 through `-target-feature +reserve-x30`
* the backend through `-mattr=+reserve-x30`
* a subtarget feature `reserve-x30`

the same way we're doing for the other registers.

Summary:
They all match the base implementation in
TargetInstrInfo::isUnpredicatedTerminator.

Follow up to D62749.

Reviewers: echristo, MaskRay, hfinkel

Reviewed By: echristo

Subscribers: wuzish, nemanjai, hiraditya, kbarton, llvm-commits, srhines

Tags: #llvm

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

This patch adds builtins for logical ops:
- svand, svbic, sveor, svorr, svcnot, svnot

and builtins for predicate operations:
- svand_b_z, svbic_b_z, sveor_b_z, svnand_b_z, svnor_b_z, svorn_b_z, svorr_b_z
- svbrka_b_z, svbrkb_b_z, svbrkpa_b_z, svbrkpb_b_z, svbrkn_b_z
- svpfirst_b
- svpnext
- svptest_any
- svptest_first
- svptest_last

This changes the logic with lowering fp16 bitcasts to always produce
either a VMOVhr or a VMOVrh, instead of only trying to do it with
certain surrounding nodes. To perform the same optimisations demand bits
and known bits information has been added for them.

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