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
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
(d618f1c, e0ac46e).
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.
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
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
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
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
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:
7b5b5dcbf9/Fortran/gfortran/regression/alloc_comp_assign_1.f90 (L50)
Reviewed By: klausler, tblah
Differential Revision: https://reviews.llvm.org/D156364
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.
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
This patch adds support to lower the link clause on OpenACC
declare construct in module declaration.
Depends on D156463
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156464
This patch adds support to lower the device_resident clause on OpenACC
declare construct in module declaration.
Depends on D156457
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156463
This patch adds support to lower the copyin clause on OpenACC
declare construct in module declaration.
Depends on D156353
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156457
Add the acc.global_dtor when lowering the OpenACC declare
construct.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156353
This relocation type is often used for debug information on Windows. We
would previously abort due to the unreachable for the unhandled
relocation type. Add support for this to prevent LLDB from aborting if
it encounters this relocation type.
This fixes a code gen issue where savings the swift async context
register (x22) accidentally overwrites the saved value of another
callee-saved register, corrupts its value and causes a crash.
Differential Revision: https://reviews.llvm.org/D156391
