This allows for users of the lsp transport libraries to process replies
in parallel, without overlapping/clobbering the output.

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

Api available since Windows Server 2016/Windows 10 1607

Reviewed By: vitalybuka

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

These test cases are checking specific functions in call stacks.
But if the call stack order is changed (e.g. another function is not inlined),
the frame number would be different.
This patch loose the frame number checks for those conditions.

Depends on D139827

Reviewed By: vitalybuka

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

I actually visited each link and added relevant context directly to the code.

This is related to the effort to eliminate internal bug tracker links
(d618f1c3, e0ac46e6).

Test files still have a lot of rdar links and ids in them.
I haven't touched them yet.

If JITLinkGeneric::linkPhase2 receives an Error rather than an InFlightAlloc
then we need to call JITLinkContext::notifyFailed, rather than calling
abandonAllocAndBailOut -- the latter asserts that there is an allocation to
abandon, and this was turning allocation errors into assertion failures in
debug mode.

The code was written with the implicit assumption that each IMPLICIT_DEF either a) the tied operand, or b) an untied source, but not both. This is true right now, but an upcoming change may allow CSE of IMPLICIT_DEFs in some cases, so let's rewrite the code to handle that possibility.

I added an MIR case which demonstrates the multiple use IMPLICIT_DEF. To my knowledge, this is not a reachable configuration from IR right now.

As an aside, this makes the structure a much closer match with the sub-reg liveness case, and we can probably just merge these routines. (Future work.)

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

insertelement instructions.

If the original vector has undef, not poison values, which are not
rewritten by later insertelement instructions, need to transform shuffle
with the undef vector, not a poison vector, and actual indices, not
PoisonMaskElem, otherwise the transformation may produce more poisons
output than the input.

[llvm-profdata] Refactoring Sample Profile Reader to increase FDO build speed using MD5 as key to Sample Profile map

This is phase 1 of multiple planned improvements on the sample profile loader.   The major change is to use MD5 hash code ((instead of the function itself) as the key to look up the function offset table and the profiles, which significantly reduce the time it takes to construct the map.

The optimization is based on the fact that many practical sample profiles are using MD5 values for function names to reduce profile size, so we shouldn't need to convert the MD5 to a string and then to a SampleContext and use it as the map's key, because it's extremely slow.

Several changes to note:

(1) For non-CS SampleContext, if it is already MD5 string, the hash value will be its integral value, instead of hashing the MD5 again. In phase 2 this is going to be optimized further using a union to represent MD5 function (without converting it to string) and regular function names.

(2) The SampleProfileMap is a wrapper to *map<uint64_t, FunctionSamples>, while providing interface allowing using SampleContext as key, so that existing code still work. It will check for MD5 collision (unlikely but not too unlikely, since we only takes the lower 64 bits) and handle it to at least guarantee compilation correctness (conflicting old profile is dropped, instead of returning an old profile with inconsistent context). Other code should not try to use MD5 as key to access the map directly, because it will not be able to handle MD5 collision at all. (see exception at (5) )

(3) Any SampleProfileMap::emplace() followed by SampleContext assignment if newly inserted, should be replaced with SampleProfileMap::Create(), which does the same thing.

(4) Previously we ensure an invariant that in SampleProfileMap, the key is equal to the Context of the value, for profile map that is eventually being used for output (as in llvm-profdata/llvm-profgen). Since the key became MD5 hash, only the value keeps the context now, in several places where an intermediate SampleProfileMap is created, each new FunctionSample's context is set immediately after insertion, which is necessary to "remember" the context otherwise irretrievable.

(5) When reading a profile, we cache the MD5 values of all functions, because they are used at least twice (one to index into FuncOffsetTable, the other into SampleProfileMap, more if there are additional sections), in this case the SampleProfileMap is directly accessed with MD5 value so that we don't recalculate it each time (expensive)

Performance impact:
When reading a ~1GB extbinary profile (fixed length MD5, not compressed) with 10 million function names and 2.5 million top level functions (non CS functions, each function has varying nesting level from 0 to 20), this patch improves the function offset table loading time by 20%, and improves full profile read by 5%.

Reviewed By: davidxl, snehasish

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

The example describing bitcasts (and memory layout) involving
vector types was incorrect for little endian.

This was reported in https://reviews.llvm.org/D94964

Previously when objcopy generated section headers, it padded the LEB
that encodes the section size out to 5 bytes, matching the behavior of
clang. This is correct, but results in a binary that differs from the
input. This can sometimes have undesirable consequences (e.g. breaking
source maps).

This change makes the object reader remember the size of the LEB
encoding in the section header, so that llvm-objcopy can reproduce it
exactly. For sections not read from an object file (e.g. that
llvm-objcopy is adding itself), pad to 5 bytes.

Reviewed By: jhenderson

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

`@llvm.ptrmask` is basically just `and` with a `ptr` operand. This is
a trivial combine to do with `and` (many others could also be added).

Reviewed By: nikic

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

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

This patch adds the functionality to process with a lambda the resources
obtained and returned by the resource managers in the plugins. These
processing lambdas are empty for the moment. The idea is to process them
when the resource manager mutex is acquired.

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

This patch extends the plugin resource managers to return more than one resource
per call. The return function is not extended since we do not return more than
one resource anywhere.

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

This patch improves the resource managers in the plugins by properly handling
the errors. Until now, errors when creating and destroying resources were not
propagated and were directly handled inside the resource managers. Now, all
errors are propagated as in the rest of the plugin infrastructure.

The code is now ready to implement the request/return of multiple resources in
a single getResource/returnResource call.

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

- Make a test for an internal concept libc++-only;
- Make sure that `size` and `capacity` in a test container return the
  same type on all platforms.

Prevent these tests from failing on some platforms (the number of
constexpr steps increased by https://reviews.llvm.org/D154860).

1. Using ADT/Bitfields.h for hash computation; this is equivalent but shorter than the existing implementation
2. Getting rid of Layout indices for stale matching; using BB->getIndex for indexing

Reviewed By: Amir

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

This required two substantial changes:
1. Moving a `getRegBitWidth(TargetRegisterClass)` overload out of Utils
   and into CodeGen
2. Passing the string function name to AMDGPUPALMetadata instead of the
   MachineFunction

Other changes are minor or updates to accommodate the first two.

See issue #64166 for more information on the layering issue.

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

Reviewed By: #libc, Mordante

Spies: Mordante, libcxx-commits

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

The single-iterator algorithms have an implementation for `false` and `true`, which are almost identical. Instead of writing two functions, this refactors the code to take the value searched for as a template parameter. This avoids a lot of code duplication and makes it easier to reason about the algorithm and their difference.

Reviewed By: #libc, Mordante

Spies: Mordante, libcxx-commits

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

lldb needs the `std` clang module to make all of libc++ available in the debugger. Make a new header to include the rest of the public headers and use to build a `std` module that just re-exports the rest of libc++.

Reviewed By: Mordante, JDevlieghere, #libc

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

Fix failure at https://lab.llvm.org/buildbot/#/builders/230/builds/16380

add --target=x86_64-unknown-linux-gnu to match FileCheck.

add -c to suppress the irrelevant warning about mktemp.

Change-Id: I8b36e76a227f079b7518b25fc2127b36008e3437

This is a speculative fix for the lldb API test suite
Build bot failures see: https://green.lab.llvm.org/green/view/LLDB/job/as-lldb-cmake/3262/

Using masks and bounds that are magic numbers means that defects
in bounds checking and offset masking are subtle and hard to
detect. https://reviews.llvm.org/D152841 is an example of this
type of defect. Switching to clearly readable library functions
makes defects less obfuscated.

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

It looks like a regression after D151737: shape of the elemental
call became rank-0.

Reviewed By: klausler

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

When creating a temporary for conflicting LHS and RHS we have to deep copy
the dynamic (allocatable, automatic) components from RHS to the temp.
Otherwise, the conflict may still be present between LHS and temp.

gfortran/regression/alloc_comp_assign_1.f90 is an example where the current
runtime code produces wrong result:
https://github.com/llvm/llvm-test-suite/blob/7b5b5dcbf9bdde729a14722eb67f9c3ab01647c7/Fortran/gfortran/regression/alloc_comp_assign_1.f90#L50

Reviewed By: klausler, tblah

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

This reverts commit 96ff464d.

The test in this change was failing on many buildbots:

https://lab.llvm.org/buildbot/#/builders/164/builds/41292
https://lab.llvm.org/buildbot/#/builders/258/builds/4491
https://lab.llvm.org/buildbot/#/builders/192/builds/3566
https://lab.llvm.org/buildbot/#/builders/123/builds/20411
https://lab.llvm.org/buildbot/#/builders/58/builds/42553
https://lab.llvm.org/buildbot/#/builders/247/builds/7037
https://lab.llvm.org/buildbot/#/builders/139/builds/46259
https://lab.llvm.org/buildbot/#/builders/216/builds/24650
https://lab.llvm.org/buildbot/#/builders/234/builds/12571
https://lab.llvm.org/buildbot/#/builders/232/builds/12574
https://lab.llvm.org/buildbot/#/builders/235/builds/975

These are small include-only changes in the AArch64 and ARM backends
that seem sufficiently small to commit separately without review.

See issue #64166 for more information about layering.

These are small include-only changes in the X86, Mips, and SystemZ
backend that seem sufficiently small to commit separately without
review.

See issue #64166 for more information about layering.

https://github.com/llvm/llvm-project/issues/64174

https://github.com/llvm/llvm-project/issues/64167

By default, clang assumes HIP kernels are launched with uniform block size,
which is the case for kernels launched through triple chevron or
hipLaunchKernelGGL. Clang adds uniform-work-group-size function attribute
to HIP kernels to allow the backend to do optimizations on that.

However, in some rare cases, HIP kernels can be launched
through hipExtModuleLaunchKernel where global work size is specified,
which may result in non-uniform block size.

To be able to support non-uniform block size for HIP kernels,
an option `-f[no-]offload-uniform-block is added. This option
is generic for offloading languages. Its default value is on for
CUDA/HIP and off otherwise.

Make -cl-uniform-work-group-size an alias to -foffload-uniform-block.

Reviewed by: Siu Chi Chan, Matt Arsenault, Fangrui Song, Johannes Doerfert

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

Fixes: SWDEV-406592

Before applying this fix, clang would not include the specified library
path arguments:

    $ ./bin/clang --target=hexagon-unknown-linux-musl  -o tprog tprog.o -L/tmp -###
    ...
    clang: warning: argument unused during compilation: '-L/tmp' [-Wunused-command-line-argument]
     "/local/mnt/workspace/install/clang-latest/bin/ld.lld" "-z" "relro" "-o" "tprog" "-dynamic-linker=/lib/ld-musl-hexagon.so.1" "/usr/lib/crt1.o" "-L/usr/lib" "tprog.o" "-lclang_rt.builtins-hexagon" "-lc"

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