In D152070 we added many new intrinsic types required for the RISC-V
Vector Extension.

This was crashing when loading the AST as those types are intrinsically
added to the AST (they don't come from the disk).

The total number required now by clang exceeds 400 so increasing the
value to 500 solves the problem. This value was already increased in
D92715 but I assume this has some impact on the on-disk format.

Also add a static assert to avoid this happening again in the future.

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

Add unit test triggering an assertion with abfeda5a.

Restriction to ModuleOp is ancient and unnecessarily restrictive.

This makes it such that new.cpp contains only the definitions of
operator new and operator delete, like its libc++abi counterpart.

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

Avoid inserting the freeze if not necessary, as this allows LVI
to continue reasoning about the expression.

After each iteration of the function specializer, constant stack values
are promoted to constant globals in order to enable recursive function
specialization. This should also be done once before running the
specializer. Enables specialization of _QMbrute_forcePdigits_2 from
SPEC2017:548.exchange2_r.

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

This patch implements the "__kmp_print_tdg_dot" function, that prints a task dependency graph into a dot file containing the tasks and their dependencies.

It is activated through a new environment variable "KMP_TDG_DOT"

Reviewed By: tianshilei1992

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

SplitBlockAndInsertIfThen utility creates two new blocks,
they're called ThenBlock and Tail (true and false destinations of a conditional
branch correspondingly). The function has a bool parameter Unreachable,
and if it's set, then ThenBlock is terminated with an unreachable.
At the end of the function the new blocks are added to the loop of the split
block. However, in case ThenBlock is terminated with an unreachable,
it cannot belong to any loop.

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

The LLVM comdat operation specifies how to deduplicate globals with the
same key in two different object files. This is necessary on Windows
where e.g. two object files with linkonce globals will not link unless
a comdat for those globals is specified. It is also supported in the ELF
format.

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

Implement XCVbitmanip intrinsics for CV32E40P according to the specification.

This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P.

Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, @simoncook, @xmj.

Spec: https://github.com/openhwgroup/cv32e40p/blob/62bec66b36182215e18c9cf10f723567e23878e9/docs/source/instruction_set_extensions.rst

Reviewed By: craig.topper

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

The operations.cpp file contained the implementation of a ton of
functionality unrelated to just the filesystem operations, and
filesystem_common.h contained a lot of unrelated functionality as well.

Splitting this up into more files will make it possible in the future
to support parts of <filesystem> (e.g. path) on systems where there is
no notion of a filesystem.

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

A few tests were also straightforward to translate to SFINAE tests
instead, so in a few cases I did that and removed the .fail.cpp test
entirely.

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

For consistency with other algorithms.

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

These are leftover hacks from using asm declaratios to access
intrinsics.

Key changes:
  - Refactor the createTargetData function to make use of the emitOffloadingArrays and emitOffloadingArraysArgument functions to generate code.
  - Added a new emitIfClause helper function to allow handling if clauses in a similar fashion to Clang.
  - Updated the MLIR side of code to account for changes to createTargetData.

Depends on D149872

Reviewed By: jdoerfert

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

This register is used as the pointer to the current thread
local storage block and is read from NT_ARM_TLS on Linux.

Though tpidr will be present on all AArch64 Linux, I am soon
going to add a second register tpidr2 to this set.

tpidr is only present when SME is implemented, therefore the
NT_ARM_TLS set will change size. This is why I've added this
as a dynamic register set to save changes later.

Reviewed By: omjavaid

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

This reverts commit aa495214.

As discussed in https://github.com/llvm/llvm-project/issues/53475 this patch
allows for using LLD-as-a-lib. It also lets clients link only the drivers that
they want (see unit tests).

This also adds the unit test infra as in the other LLVM projects. Among the
test coverage, I've added the original issue from @krzysz00, see:
https://github.com/ROCmSoftwarePlatform/D108850-lld-bug-reproduction

Important note: this doesn't allow (yet) linking in parallel. This will come a
bit later hopefully, in subsequent patches, for COFF at least.

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

The wrapper, as most of compiler-generated functions, are intended to serve the
IR for the current module. The safest linkage is to keep these private to avoid
any possible collision with other modules.

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

This was a spurious closing parenthese.

The ConstantRange specifies the range of the scalar elements in the
vector. When converting into a Constant, we need to create a vector
splat with the correct type. For that purpose, pass in the expected
type for the constant.

Fixes https://github.com/llvm/llvm-project/issues/63380.

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

I setup a simple test with a large .so (~100MiB) that was only present on the target machine
but not present on the local machine, and ran a lldb server on the target and connectd to it.

LLDB properly downloads the file from the remote, but it does so at a very slow speed, even over a hardwired 1Gbps connection!

Increasing the buffer size for downloading these helps quite a bit.

Test setup:

```
$ cat gen.py
print('const char* hugeglobal = ')

for _ in range(1000*500):
    print('  "' + '1234'*50 + '"')

print(';')
print('const char* mystring() { return hugeglobal; }')
$ gen.py > huge.c
$ mkdir libdir
$ gcc -fPIC huge.c -Wl,-soname,libhuge.so -o libdir/libhuge.so -shared
$ cat test.c
#include <string.h>
#include <stdio.h>
extern const char* mystring();
int main() {
        printf("%d\n", strlen(mystring()));
}
$ gcc test.c -L libdir -l huge -Wl,-rpath='$ORIGIN' -o test
$ rsync -a libdir remote:~/
$ ssh remote bash -c "cd ~/libdir && /llvm/buildr/bin/lldb-server platform --server --listen '*:1234'"
```

in another terminal

```
$ rm -rf ~/.lldb # clear cache
$ cat connect.lldb
platform select remote-linux
platform connect connect://10.0.0.14:1234
file test
b main
r
image list
c
q
$ time /llvm/buildr/bin/lldb --source connect.lldb
```

Times with various buffer sizes:

1kiB (current): ~22s
8kiB: ~8s
16kiB: ~4s
32kiB: ~3.5s
64kiB: ~2.8s
128kiB: ~2.6s
256kiB: ~2.1s
512kiB: ~2.1s
1MiB: ~2.1s
2MiB: ~2.1s

I choose 512kiB from this list as it seems to be the place where the returns start diminishing and still isn't that much memory

My  understanding of how this makes such a difference is ReadFile issues a request for each call, and larger buffer means less round trip times. The "ideal" situation is ReadFile() being async and being able to issue multiple of these, but that is much more work for probably little gains.

NOTE: this is my first contribution, so wasn't sure who to choose as a reviewer. Greg Clayton seems to be the most appropriate of those in CODE_OWNERS.txt

Reviewed By: clayborg, jasonmolenda

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

Allows constant folding of such instructions when estimating user bonus.

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

Fold uadd.sat(X, Y) uge X and usub.sat(X, Y) ule X to true.

Proof: https://alive2.llvm.org/ce/z/596m9X

Fixes https://github.com/llvm/llvm-project/issues/63381.

Adds a new HLFIR operation for the COUNT intrinsic according to
the design set out in flang/docs/HighLevel.md. This patch includes all
the necessary changes to create a new HLFIR operation and lower it into
the fir runtime call.

Author was @jacob-crawley. Minor adjustments by @tblah

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

Codegen only supports conversions between logicals and integers. The
verifier should reflect this.

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

When the ENTRY statement is used, the same source can return different
types depending on the entry point. These different return values are
storage associated (share the same storage). Previously, this led to the
declaration of the results to all have the largest type. This patch adds
a convert between the stack allocation and the declaration so that the
hlfir.decl gets the right type.

I haven't managed to generate code where this convert converted a
reference to an allocation for a smaller type into an allocation for a
larger one, but I have added an assert just in case.

This is a different solution to https://reviews.llvm.org/D152725, see
discussion there.

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

The specialization bonus is zero in some unittests because the basic blocks
containing the users of the constant arguments are executed less frequently
than the entry block. Sinking them into loops solves that.

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

Some transformation in CodeGenPrepare pass may create and/or delete
basic block, but they don't update the LoopInfo, so the LoopInfo may
end up containing dangling pointers and sometimes reused basic blocks,
which leads to "interesting" non-deterministic behaviour.

These transformations do not seem to alter the loop structure of the
function, and updating the loop info is quite straighforward.

Reviewed By: efriedma

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

Change-Id: If8ab3905749ea6be94fbbacd54c5cfab5bc1fba1

This patch includes a test that fails without the fix.

I discovered that we weren't creating `Value`s for integer literals when, in a
different patch, I tried to overwrite the value of a struct field with a literal
for the purposes of a test and was surprised to find that the struct compared
the same before and after the assignment.

This functionality therefore seems useful at least for tests, but is probably
also useful for actual analysis of code.

Reviewed By: ymandel, xazax.hun, gribozavr2

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

Recently the AMDGPU backend automatically enables a pass to optimize
atomics. This results in the LTO build taking about 10x longer in all
cases. For now we disable this by default as was the case before the
patch in D152649.

Reviewed By: lntue

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

In https://reviews.llvm.org/D153029, I moved the loading/unloading
mechanisms of shared libraries from the JIT runner to the execution
engine in order to make that mechanism available in the latter
(including its Python bindings). However, I realized that I introduced a
small change in semantic: previously, the JIT runner checked for the
presence of init/destroy functions and only loaded the library as
JITDyLib if they were not present. After I moved the code, all libraries
were loaded as JITDyLib, even if they registered their symbols
explicitly in their init function. I am not sure if this is really a
problem but (1) the previous behavior was different and (2) I guess it
could cause a problem if some symbols are exported through the init
function *and*  have public visibility. This patch reestablishes the
original behaviour in the new place of the code.

Reviewed By: mehdi_amini

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

Fixes: https://github.com/llvm/llvm-project/issues/59119

Reviewed By: PiotrZSL

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