In passing, also use a more precise diagnostic to explain why an
expression is not an ICE if it's not of integral type.

I move the triple (de)composition logic into the builder in e5d08fcb
but this test is relying on Make to construct the set the ARCH,
ARCH_CFLAGS and SDKROOT based on the given TRIPLE. This patch updates
the test to pass these variables directly.

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

This patch adds the infrastructure to have language specific REPL init
files. It's the foundation work to a following patch that will introduce
Swift REPL init file.

When lldb is launched with the `--repl` option, it will look for a REPL
init file in the home directory and source it. This overrides the
default `~/.lldbinit`, which content might make the REPL behave
unexpectedly. If the REPL init file doesn't exists, lldb will fall back
to the default init file.

rdar://65836048

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

The behavior of the CrossOver mutator has changed with
bb54bcf8. This seems to affect the
value-profile-load test on Darwin. This patch provides a wider margin for
determining success of the value-profile-load test, by testing the targeted
functionality (i.e., GEP index value profile) more directly and faster. To this
end, LoadTest.cpp now uses a narrower condition (Size != 8) for initial pruning
of inputs, effectively preventing libFuzzer from generating inputs longer than
necessary and spending time on mutating such long inputs in the corpus - a
functionality not meant to be tested by this specific test.

Previously, on x86/Linux, it required 6,597,751 execs with -use_value_profile=1
and 19,605,575 execs with -use_value_profile=0 to hit the crash. With this
patch, the test passes with 174,493 execs, providing a wider margin from the
given trials of 10,000,000. Note that, without the value profile (i.e.,
-use_value_profile=0), the test wouldn't pass as it still requires 19,605,575
execs to hit the crash.

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

InitializeInterceptors() calls dlsym(), which calls calloc().  Depending
on the allocator implementation, calloc() may invoke mmap(), which
results in a segfault since REAL(mmap) is still being resolved.

We fix this by doing a direct syscall if interceptors haven't been fully
resolved yet.

Reviewed By: vitalybuka

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

Fixes incorrectly constructed ceill tests.

This patch prevents failures like those reported in
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/34173.

We have enabled the default constructor for
`llvm::ElementCount` to make sure the code compiles on Windows.

Reviewed By: ormris

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

Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=1119478

Patch By: haampie

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

-force-attribute adds an attribute to function via command-line.
However, there was no counter-part to remove an attribute.  This patch
adds -force-remove-attribute that removes an attribute from function.

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

There's a potential motivating case to increase this limit in PR47191:
http://bugs.llvm.org/PR47191

But first we should make it less hacky. The limit in InstCombine is directly tied
to this value because an increase there can cause asserts in the underlying value
tracking calls if not changed together. The usage in VectorUtils is independent,
but the comment suggests that we should use the same value unless there's a known
reason to diverge. There are similar limits in codegen analysis, but I think we
should leave those independent in case we intentionally want the optimization
power/cost to be different there.

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

Add the unsigned complements to the existing FPToSI and SIToFP operations in the
standard dialect, with one-to-one lowerings to the corresponding LLVM operations.

Reviewed By: ftynse

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

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

This allows the logic to be reused by both the builders and the tests.

Some code bases out there pass -mtune=generic to clang. This would have
been ignored prior to D85384. Now it results in an error
because "generic" isn't recognized by isValidCPUName.

And if we let it go through to the backend as a tune
setting it would get the tune flags closer to i386 rather
than a modern CPU.

I plan to change what tune=generic does in the backend in
a future patch. And allow this in the frontend.
But this should be a quick fix for the error some users
are seeing.

If the function is not marked exlicitly as declare target and it calls
function(s), marked as declare target device_type(host), these host-only
functions should not be dignosed as used in device mode, if the caller
function is not used in device mode too.

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

PDL presents a high level abstraction for the rewrite pattern infrastructure available in MLIR. This abstraction allows for representing patterns transforming MLIR, as MLIR. This allows for applying all of the benefits that the general MLIR infrastructure provides, to the infrastructure itself. This means that pattern matching can be more easily verified for correctness, targeted by frontends, and optimized.

PDL abstracts over various different aspects of patterns and core MLIR data structures. Patterns are specified via a `pdl.pattern` operation. These operations contain a region body for the "matcher" code, and terminate with a `pdl.rewrite` that either dispatches to an external rewriter or contains a region for the rewrite specified via `pdl`. The types of values in `pdl` are handle types to MLIR C++ types, with `!pdl.attribute`, `!pdl.operation`, and `!pdl.type` directly mapping to `mlir::Attribute`, `mlir::Operation*`, and `mlir::Value` respectively.

An example pattern is shown below:

```mlir
// pdl.pattern contains metadata similarly to a `RewritePattern`.
pdl.pattern : benefit(1) {
  // External input operand values are specified via `pdl.input` operations.
  // Result types are constrainted via `pdl.type` operations.

  %resultType = pdl.type
  %inputOperand = pdl.input
  %root, %results = pdl.operation "foo.op"(%inputOperand) -> %resultType
  pdl.rewrite(%root) {
    pdl.replace %root with (%inputOperand)
  }
}
```

This is a culmination of the work originally discussed here: https://groups.google.com/a/tensorflow.org/g/mlir/c/j_bn74ByxlQ

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

This patch was reverted in 7c182663 due to some failures
observed on PCC based machines. Failures were due to Endianness issue and
long double representation issues.

Patch is revised to address Endianness issue. Furthermore, support
for emission of `DW_OP_implicit_value` for `long double` has been removed
(since it was unclean at the moment). Planning to handle this in
a clean way soon!

For more context, please refer to following review link.

Reviewed By: aprantl

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

This patch contains the following changes:
1. Renamed the function `DeviceTy::data_exchange` to `DeviceTy::dataExchange`;
2. Changed the second argument `DeviceTy DstDev` to `DeviceTy &DstDev`;
3. Renamed the last argument.

Reviewed By: ye-luo

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

This reverts commit 15801f16.
arc's land messed up! It removed the new commit message and took it
from revision.

[AArch64][GlobalISel] Handle rtcGPR64RegClassID in AArch64RegisterBankInfo::getRegBankFromRegClass()

TargetRegisterInfo::getMinimalPhysRegClass() returns rtcGPR64RegClassID for X16
and X17, as it's the last matching class. This in turn gets passed to
AArch64RegisterBankInfo::getRegBankFromRegClass(), which hits an unreachable.

It seems sensible to handle this case, so copies from X16 and X17 work.
Copying from X17 is used in inline assembly in libunwind for pointer
authentication.

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

llvm is missing support for DW_OP_implicit_value operation.
DW_OP_implicit_value op is indispensable for cases such as
optimized out long double variables.

For intro refer: DWARFv5 Spec Pg: 40 2.6.1.1.4 Implicit Location Descriptions

Consider the following example:
```
int main() {
        long double ld = 3.14;
        printf("dummy\n");
        ld *= ld;
        return 0;
}
```
when compiled with tunk `clang` as
`clang test.c -g -O1` produces following location description
of variable `ld`:
```
DW_AT_location        (0x00000000:
                     [0x0000000000201691, 0x000000000020169b): DW_OP_constu 0xc8f5c28f5c28f800, DW_OP_stack_value, DW_OP_piece 0x8, DW_OP_constu 0x4000, DW_OP_stack_value, DW_OP_bit_piece 0x10 0x40, DW_OP_stack_value)
                  DW_AT_name    ("ld")
```
Here one may notice that this representation is incorrect(DWARF4
stack could only hold integers(and only up to the size of address)).
Here the variable size itself is `128` bit.
GDB and LLDB confirms this:
```
(gdb) p ld
$1 = <invalid float value>
(lldb) frame variable ld
(long double) ld = <extracting data from value failed>
```

GCC represents/uses DW_OP_implicit_value in these sort of situations.
Based on the discussion with Jakub Jelinek regarding GCC's motivation
for using this, I concluded that DW_OP_implicit_value is most appropriate
in this case.

Link: https://gcc.gnu.org/pipermail/gcc/2020-July/233057.html

GDB seems happy after this patch:(LLDB doesn't have support
for DW_OP_implicit_value)
```
(gdb) p ld
p ld
$1 = 3.14000000000000012434
```

Reviewed By: aprantl

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

Print which load command we were looking for when the sanity check
fails:

  AssertionError: 0 != 1 : wrong number of load commands for
  LC_VERSION_MIN_MACOSX

D81345 appears to accidentally disables vectorization when explicitly
enabled. As PGSO isn't currently accessible from LoopAccessInfo, revert back to
the vectorization with versioning-for-unit-stride for PGSO.

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

Binaries need to be code signed with entitlements to run on device.

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

This addresses the issue introduced by D86134.

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

Construct the ARCH_CFLAGS in Python rather than in Make by disassembling
the TRIPLE.

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

The argument is unused and can be removed.

The generic address space used to be 4, but the string here seems to
not matter.

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

Loads are always required to have a single memory operand.

Previously we weren't adding the LegalizerInfo to the post-legalizer
combiner. Since that's fixed, we don't need to try to filter out the
one case that was breaking.

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

D85820 introduced a full path in the LLVM_SYSTEM_LIBS property of the
LLVMSupport target, which made the OCaml bindings fail to build, since
they use -l [system_lib] flags for every lib in LLVM_SYSTEM_LIBS, which
cannot work with absolute paths.

This patch solves the issue in a similar vain as ZLIB does it: it adds
the full library path to imported_libs, and adds a stripped down version
without directories, lib prefix and lib suffix to system_libs

In the future we should probably make some changes to LLVM_SYSTEM_LIBS,
since both zlib and ncurses do not necessarily have to be system libs
anymore due to the find_package / find_library bits introduced in
D85820 and D79219.

Patch By: haampie

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

D85820 introduced a bug where LLVM_ENABLE_TERMINFO was set to true when
the library was found, even when the user had set
-DLLVM_ENABLE_TERMINFO=OFF.

Patch By: haampie

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

Was reverted because MLIR/Flang builds were broken, these APIs have been
fixed in the meantime.