This test previously ran on QEMU or A64FX both of which can/do have
512 bit SVE by default.

Graviton 3 has 256 bit SVE so the first part of the test failed.

To fix this, probe the supported vector lengths before starting
the test. The first check will use the default vector length and
the rest use either 256 or 128 bit.

Therefore this test will be skipped on a machine with only 128 bit SVE.

Reviewed By: omjavaid

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

During __do_global_dtors_aux glibc sets a flag that is right
next to the global variable. This is done using a store byte.

On QEMU the watchpoints are handled with a finer granularity
than real hardware, so this wasn't a problem. On Graviton 3
(and Mountain Jade, though this test won't run there) watchpoints
look at larger chunks of memory.

This means that the final continue actually stops in  __do_global_dtors_aux
instead of exiting.

We could fix this by padding the global to be away from the flag,
but that is fiddly and it is easier just to remove the watchpoint
before the final continue. We have already verified it worked by that
point.

Reviewed By: omjavaid

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

Running this on Amazon Ubuntu the final backtrace is:
```
(lldb) thread backtrace
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
  * frame #0: 0x0000aaaaaaaa07d0 a.out`func_c at main.c:10:3
    frame #1: 0x0000aaaaaaaa07c4 a.out`func_b at main.c:14:3
    frame #2: 0x0000aaaaaaaa07b4 a.out`func_a at main.c:18:3
    frame #3: 0x0000aaaaaaaa07a4 a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:22:3
    frame #4: 0x0000fffff7b373fc libc.so.6`___lldb_unnamed_symbol2962 + 108
    frame #5: 0x0000fffff7b374cc libc.so.6`__libc_start_main + 152
    frame #6: 0x0000aaaaaaaa06b0 a.out`_start + 48
```
This causes the test to fail because of the extra ___lldb_unnamed_symbol2962 frame
(an inlined function?).

To fix this, strictly check all the frames in main.c then for the rest
just check we find __libc_start_main and _start in that order regardless
of other frames in between.

Reviewed By: omjavaid

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

Add functions AMDGPU::DepCtr::encodeField*() and AMDGPU::DepCtr::decodeField*()
for each of vm_vsrc, va_vdst and sa_sdst. These are now used in
AMDGPUInsertDelayAlu and GCNHazardRecognizer so as to make working with
S_WAITCNT_DEPCTR operands easier and more readable.

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

We started seeing new failure after D142886. Looks like it enabled new cases and we hit an assert:
assert(Current->getNumDefinedValues() == 1 &&
           "only recipes with a single defined value expected");

 When we do instruction sinking for the first order recurrence we hit an assert if instruction doesn't have single def. In case instruction doesn't produce any new def there is no new users and nothing to sink.

Reviewed By: fhahn

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

Reviewed By: olista01

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

  * Update cortex-a510 and neoverse-v2 SVE scheduling so that pseudos
have the same instruction latency as original instruction.

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

  * SVE pseudos don't pick up the right latency information during MI
    scheduling as the regex do not match with instruction name.

  * Move UNDEF, PSEUDO, and ZERO to the end of actual SVE instruction

  * Some CPUs *td files will be fixed in the next commit

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

The ARM backend codebase is dotted with places where armv6-m will generate
constant pools. Now that we can generate execute-only code for armv6-m, we need
to make sure we use the movs/lsls/adds/lsls/adds/lsls/adds pattern instead of
these.

Big stacks is one of the obvious places. In this patch we take care of two
sites:
1. take care of big stacks in prologue/epilogue
2. take care of save/tSTRspi nodes, which implicitly fixes
   emitThumbRegPlusImmInReg which is used in several frame lowering fns

Reviewed By: efriedma

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

genElementalCall can return a null option when lowering elemental
subroutine calls (as there is no return value). Therefore
std::option::value should not be used as it will cause an
assertion failure.

This fixes uses of the mvbits intrinsic with array arguments, as used in
the gfortran test suite.

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

This adds support for dynamically optional arguments for intrinsics
which do not have their own hlfir operations.

The functions for processing these arguments are mostly the same as the
equivalent functions in ConvertExpr.cpp. I chose not to share
implementations so that HLFIR helpers can be used here. Presumably
ConvertExpr.cpp will go away one day.

Depends on D154236

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

This also adds support for allocatable non-optional arguments.

Of the transformational intrinsics which currently have their own hlfir
operations, all of the dynamically optional arguments are lowered as
boxes, so that is all that is implemented for now.

One alternative approach would have been to deal with the dynamically
optional arguments when lowering to FIR runtime calls. I decided not to
do this so that any passes working on the intrinsic operations would not
have to know about and handle the dynamically optional arguments.

Depends on D154235

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

The old code had overgrown itself and become difficult to read and
modify. I've rewritten it and moved it into its own translation unit.

I moved PreparedActualArgument to the header file for the
transformational intrinsic lowering. Logically, it belongs in
ConvertCall.h, but putting it there would create a circular dependency
between HlfirIntrinsics and ConvertCall.

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

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

Preparatory refactoring for the upcoming support of new range check form
to parse.

With this change we always set Index and End values together in the same
place.

parseRangeCheckICmp specification updated.

Reviewed By: skatkov
Differential Revision: https://reviews.llvm.org/D154156

This reverts commit 048764f2.

Breaks https://lab.llvm.org/buildbot/#/builders/61/builds/45451

Currently crashes if function isn't void when specifiying
'-entry-point-result=void'.

Reviewed By: jpienaar

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

Reviewed By: zixuan-wu

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

Reviewed By: zixuan-wu

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

IIUC, the `default` case should be unreachable inferred from the context.

Reviewed By: kkwli0

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

This transform op promotes loops with one iteration. I.e., the loop op is replaced by just the loop body.

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

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

Reviewed By: gysit

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

Refactor lowerToScalableOp to combine switch case code.

Reviewed By: frasercrmck

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

This commit adds LLVM's unnamed_addr enum to LLVMFuncOp.

Reviewed By: gysit

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

This will allow targets to lower their 'copy' instructions easily.

Reviewed By: arsenm

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

Reverts 4986f3f2 (but keeps its unit tests) and fixes #49973
differently.

Also fixes bugs that incorrectly annotate the operator keyword as
TT_FunctionDeclarationName in function calls and as TT_Unknown in function
declarations and definitions.

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

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

If an attribute is implied by the IR we do not (always) create an AA
anymore. To keep test coverage, and given the lack of a good heuristic
to decide otherwise, we will now also manifest such attributes.

Checking more than one attribute kind was never done and we want to
later check the IR w/o creating an AA as fallback.

This patch improves compatibility with GNU assembler by adding support for
constant immediate in la and lla pseudo instruction, and expanding it in the
same way as we currently expands li pseudo instruction.

Links to discussion related to the above issue in the community -
https://github.com/riscv-non-isa/riscv-arch-test/issues/105
https://github.com/riscv-non-isa/riscv-arch-test/issues/108
https://github.com/riscv-non-isa/riscv-arch-test/issues/106

Reviewed By: craig.topper

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

Reviewed By: craig.topper

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

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

This change lifts the limitation that only the trailing dimensions/sizes
in dynamic index lists can be scalable. It allows us to extend
`MaskedVectorizeOp` and `TileOp` from the Transform dialect so that the
following is allowed:

  %1, %loops:3 = transform.structured.tile %0 [[4], [4], 4]

This is also a follow up for https://reviews.llvm.org/D153372
that will enable the following (middle vector dimension is scalable):

  transform.structured.masked_vectorize %0 vector_sizes [2, [4], 8]

To facilate this change, the hooks for parsing and printing dynamic
index lists are updated accordingly (`printDynamicIndexList` and
`parseDynamicIndexList`, respectively). `MaskedVectorizeOp` and `TileOp`
are updated to include an array of attribute of bools that captures
whether the corresponding vector dimension/tile size, respectively, are
scalable or not.

This change is a part of a larger effort to enable scalable
vectorisation in Linalg. See this RFC for more context:
  * https://discourse.llvm.org/t/rfc-scalable-vectorisation-in-linalg/

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

Move to `DumpAddress` in c4a8a760.

Restructure the loop as suggested in D154264 to increase readability and
make it easier to extend.

Originally the symbol file format was going to textual, before we
decided to use JSON. Updated the plugin name and the header guard.

We recently saw an uptick in internal reports complaining that LLDB is
slow when sources on network file systems are inaccessible. I looked at
the SourceManger and its cache and I think there’s some room for
improvement in terms of reducing file system accesses:

 1. We always resolve the path.
 2. We always check the timestamp.
 3. We always recheck the file system for negative cache hits.

D153726 fixes (1) but (2) and (3) are necessary because of the cache’s
current design. Source files are cached at the debugger level which
means that the source file cache can span multiple targets and
processes. It wouldn't be correct to not reload a modified or new file
from disk.

We can however significantly reduce the number of file system accesses
by using a two level cache design: one cache at the debugger level and
one at the process level:

 - The cache at the debugger level works the way it does today. There is
   no negative cache: if we can't find the file on disk, we'll try again
   next time the cache is queried. If a cached file's timestamp changes
   or if its path remapping changes, the cached file is evicted and we
   reload it from disk.
 - The cache at the process level is design to avoid accessing the file
   system. It doesn't check the file's modification time. It caches
   negative results, so if a file didn't exist, it doesn't try to reread
   it from disk. Checking if the path remapping changed is cheap
   (doesn't involve checking the file system) and is the only way for a
   file to get evicted from the process cache.

The result of this patch is that LLDB will not show you new content if a
file is modified or created while a process is running. I would argue
that this is what most people would expect, but it is a change from how
LLDB behaves today.

For an average stop, we query the source cache 4 times. With the current
implementation, that's 4 stats to get the modification time, If the file
doesn't exist on disk, that's an additional 4 stats. Before D153726, if
the path starts with a ~ there are another additional 4 calls to
realpath. When debugging sources on a slow (network) file system, this
quickly adds up.

In addition to the two level caching, this patch also adds a source
logging channel and synchronization to the source file cache. The
logging was helpful during development and hopefully will help us triage
issues in the future. The synchronization isn't a new requirement: as
the cache is shared across targets, there is no guarantees that it can't
be accessed concurrently. The patch also fixes a bug where we would only
set the source remapping ID if the un-remapped file didn't exist, which
led to the file getting evicted from the cache on every access.

rdar://110787562

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