This patch fixes a 32bit integer overflow in lldb-vscode.
The current implementation of frame_id does `(thread_index << 19 | frame_index)`. Since thread_index is a 32 bit integer this leaves only 32 - 19 == 13 bits available for the thread_index. As a result, lldb-vscode can only handle 2^13 == 8192 threads. Normally, this would be sufficient, but we have seen crazy process having +12000 threads, causing the frame_id algorithm above to integer overflow during casting.

The patch fixes the overflow by up casting to 64 bit integer first before bit shifiting.

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

Without any additional tweaking, we can successfully legalize for wider
types (i64, i96 for rv32; i128, i192 for rv64) that are integer
multiples of XLen.

Reviewed By: arsenm, craig.topper

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

Split off min-max in-loop reduction tests into separate file and extend
them by adding tests with
 * min & max intrinsics
 * fmuladd with permuted operands
 * min & max select tests with permuted operands.

Adds extra test coverage as suggested in D155845.

llvm.sqrt.f64 now works correctly and should be called directly.

https://reviews.llvm.org/D156366

Adds representation for `acc routine` under new operation named
`acc.routine`. This operation is associated with a function symbol.
It also gets its own compiler generated synthetic symbol name so
that it can be referenced from the associated function. The clauses
associated with the `acc routine` directive are captured in the
`acc.routine` op.

The linking between the `func.func` and its `acc.routine` declaration
is done through the `acc.routine_info` attribute. In practice, a
single `acc routine` is associated with a function. But the spec does
not specifically restrict this - thus the 1:N relationship between
`func.func` and `acc.routine` allowed in the dialect. Additionally, it
makes sense that multiple acc routines could be used for a single
function depending on loop context - to allow flexible parallelization.

Most acc routine clauses are supported including `gang`, `gang(dim:)`,
`vector`, `worker`, `seq`, `nohost`, and `bind`. The only one not
supported is `device_type`. This is because most other clauses also
miss this and the effort to add support for it needs to be coordinated
and consistent.

Reviewed By: clementval, vzakhari

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

The name is not really descriptive, renamed the file and improved the
diagnostics.

As a drive-by fixes one macro to generate a diagnostic.

Reviewed By: #libc, jloser, philnik

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

Without RUN: in the continuation lines, they just test a quirk of -###
that clang returns with 0.

ELF object files can contain `.ctors` and `.dtors` sections that also
participate as initializers.

Reviewed By: lhames

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

OnUnmap will tag it to zero anyway.

Reviewed By: fmayer

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

Jump tables may contain a function start address. One real-world example
is when a target basic block contains a recursive tail call that is
later optimized/folded into a jump table target.

While analyzing a jump table, we treat start address similar to an
address past the end of the containing function (a result of
__builtin_unreachable), i.e. we require another "regular" entry for the
heuristic to proceed.

Reviewed By: Amir

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

Async signals may crash the process if AsanThread is not fully
initialized. We do the same for other sanitizers already.

Can't have good reproducer for test. We see this in internal test with prob 1e-6.

Reviewed By: kstoimenov

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

start_data_ is platform specific.

Reviewed By: kstoimenov

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

This reverts commit 673a4671.

Depends on reverted commit 0cab8d20.

That commit was reverted due to an LTO crash. I've put a reduced
test case here: https://github.com/llvm/llvm-project/issues/64114

This reverts commit 0cab8d20.

Reverted due to an LTO crash. I've put a reduced test case here:
https://github.com/llvm/llvm-project/issues/64114

Consider the following statement:
    void* foo = ((void *)0);

For the sub-AST:
    | `-ImplicitCastExpr 'const void *' <NullToPointer>
    |   `-CStyleCastExpr 'void *' <NullToPointer>
    |     `-IntegerLiteral 'int' 0

If the subexpression of the cast is itself the NULL constant, then
ImplicitCastExpr should emit the NULL pointer constant.

Reviewed By: efriedma

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

Reviewed By: kstoimenov

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

Reviewed By: wallace

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

This reuses the patterns introduced to help lower vnsr[a,l].vx in D155698.

Reviewed By: craig.topper

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

Similar to D155698 where the shift amount is extended, this patch extends the
ComplexPattern to handle the case where the shift amount has been truncated.
Truncations are custom lowered to truncate_vector_vl, and in cases like i64 ->
i16 they are truncated by one power of two at a time, so we need to unravel
nested layers of them.

The pattern can also be reused for Zvbb's vwsll.vx in an upcoming patch.

Reviewed By: craig.topper

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

Reviewed By: craig.topper

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

This reverts commit eaf6117f (D155520).
There's an ASAN build failure that needs investigation.

This patch adds support for `fread` on the GPU via the RPC mechanism.
Here we simply pass the size of the read to the server and then copy it
back to the client via the RPC channel. This should allow us to do the
basic operations on files now. This will obviously be slow for large
sizes due ot the number of RPC calls involved, this could be optimized
further by having a special RPC call that can initiate a memcpy between
the two pointers.

Reviewed By: jdoerfert

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

The expected number for the max ptrdiff value was expected to be exactly
4294967296 (2**32) for 32 bit systems, when it should be
4294967295 (2**32 - 1). This also adds a second test to check for this
case on non-32 bit systems.

Reviewed By: lntue, mikhail.ramalho

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

If a function contains inline function ranges whose address ranges are not contained in the parent scope, then emit an error message and omit them from the final GSYM. Prior to this we would only test if an inline function's address range was within the concrete function's ranges. If we ran into a case where the inline range was within the function's ranges, but not within one of the parent inline function's ranges, then we would fail to produce a GSYM file and exit with an error.

The current code will emit full details on invalid inline ranges as they are being parsed and will omit any bad ranges from the final GSYM file.

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

The if-clause on 'target teams loop' should only accept "target" as a
directive name modifier. Any other directive name should generate an
error.

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

https://reviews.llvm.org/D153983 introduced a new .td file with
attributes and enums. This patch adds the corresponding rules to the
BUILD file in order to fix the bazel build.

Reviewed By: ingomueller-net

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

This patch adds mix-in classes for the Python bindings of
`EmptyTensorToAllocTensorOp` and `OneShotBufferizeOp`. For both classes,
the mix-in add overloads to the `__init__` functions that allow to
construct them without providing the return type, which is defaulted to
the only allowed type and `AnyOpType`, respectively.

Note that the mix-in do not expose the
`function_boundary_type_conversion` attribute. The attribute has a
custom type from the bufferization dialect that is currently not exposed
in the Python bindings. Handling of that attribute can be added easily
to the mix-in class when the need arises.

Reviewed By: springerm

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

Summary:
These fail tests, disbale them until we can figure out how to get them
passing.

For Pseudos that end in _MASK or should be forceMasked,
which means that in the case that the instruction should be
mask undisturbed the destination register must be read to
determine the undisturbed values. This patch adds a SchedRead
that gets passed to MASK pseudos to represent this extra read that
must occur.

A future patch should do something similiar for when a pseudo is TU,
since those instructions must also read their destination to preserve
undisturbed-ness.

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

`inverse.ballot` checks if a cc bit is set for the current
lane. Therefore, it is not convergent.

Reviewed By: sameerds

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

Recommit only the tests that look good this time.

Correct X86 strictfp tests to follow the rules documented in the LangRef:
https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics

Mostly these tests just needed the strictfp attribute on function
definitions. After D154991 the constrained intrinsics have the
strictfp attribute by default so they don't need it here, but other
functions do.

Test changes verified with D146845.

This patch introduces per kernel environment. Previously, flags such as execution mode are set through global variables with name like `__kernel_name_exec_mode`. They are accessible on the host by reading the corresponding global variable, but not from the device. Besides, some assumptions, such as no nested parallelism, are not per kernel basis, preventing us applying per kernel optimization in the device runtime.

This is a combination and refinement of patch series D116908, D116909, and D116910.

Depend on D155886.

Reviewed By: jdoerfert

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

hasPredecessorHelper method, that is used by DAGCombiner to combine to pre-indexed and post-indexed load/stores, is a major source of slowdown while compiling a large function with MSan enabled on Arm. This patch caps the DFS-graph traversal for this method to 8192 which cuts compile time by 50% (4m -> 2m compile time) at the cost of less overall nodes combined.

Here's the summary of pre-index DAG nodes created and time it took to compile the pathological case with different MaxDepth limit:
1. With MaxDepth = 0 (unlimited): 1800, took 4m
2. With MaxDepth = 32k, 560, took 2m31s
3. With MaxDepth = 8k, 139, took 2m.

Reviewed By: MaskRay

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

When we build the Clang module compilation command (e.g., when
a user requests import of a module via `expression @import Foundation`),
LLDB will try to determine which SDK directory to use as the `sysroot`.
However, it currently does so by simply enumerating the `SDKs` directory
and picking the last one that's appropriate for module compilation
(see `PlatformDarwin::GetSDKDirectoryForModules`). That means if we have
multiple platform SDKs installed (e.g., a public and internal one), we
may pick the wrong one by chance.

On Darwin platforms we emit the SDK path that a object
file was compiled against into DWARF (using `DW_AT_LLVM_sysroot`
and `DW_AT_APPLE_sdk`). For Swift debugging, we already parse the SDK
path from debug-info if we can.

This patch mimicks the Swift behaviour for non-Swift languages. I.e.,
if we can get the SDK path from debug-info, do so. Otherwise, fall back
to the old heuristic.

rdar://110407148

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