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

The make_shared function never returns a nullptr, as such the test for nullptr
is not needed. We also move the empty string check earlier in the if
("oso_object"), as this is cheaper than loading the object file.

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

Allow computing size of interposable or externally initializable global variables.

Reviewed By: nikic

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

[libc++][Modules] std.functional.__functional.invoke and std.type_traits.underlying_type can't export std.type_traits

`__functional/invoke.h` currently only includes `__type_traits/invoke.h` and not all of `type_traits`. Keep it using the specific header, and update its export. Similarly, `__type_traits/underlying_type.h` currently only includes `__type_traits/is_enum.h`, so update its export as well. This requires adding lots of export statements to the module map to keep the transitive includes working. Adding direct includes to the headers fixes `check-cxx`, but leaves many `run-buildbot generic-modules` tests failing, some even with linker errors.

Reviewed By: ldionne, #libc

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

Don't emit a warning when a compile-time constant argument to
ISNAN() or IEEE_IS_NAN() is a NaN.

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

-fno-hip-fp32-correctly-rounded-divide-sqrt affects clang codegen
and should be passed to clang -cc1 by clang driver.

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

Reviewed by: Matt Arsenault

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

This patch temporarily disables tests that require the subprocess
executor as they are currently flaky on systems that are able to run
them such as clang-cmake-x86_64-avx512-linux. Once I have a fix for the
flakiness they will be reenabled.

Apply compile-time checks to the values supplied for the POS and LEN
arguments of the IBITS intrinsic function even when only one of them
is a known constant.

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

The overflow detection code in the templates that fold SUM and PRODUCT
was checking for overflow before performing the reduction, not after.
Fix and add tests.

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

Emit warnings when CHARACTER lengths or array sizes of actual
and dummy arguments mismatch in risky ways.

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

We want to move away from those tests and towards explicit .verify.cpp
tests, since those have a simpler model.

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

The common GPU operation transformation that lowers `math` operations
to function calls in the `gpu-to-nvvm` and `gpu-to-rocdl` passes handles
`vector` types by applying the function to each scalar and returning a
new vector. However, there was a typo that results in incorrectly
accumulating the result vector, and the rewrite returns an `llvm.mlir.undef`
result instead of the correct vector. A patch is added and tests are
strengthened.

Reviewed By: ThomasRaoux

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

In the MLIR dataflow analysis framework, when an `AnalysisState` is updated, it's dependents are enqueued to be visited.

Currently, there are two ways dependents are managed:

* `AnalysisState::dependents` stores a list of dependents. `DataFlowSolver::propagateIfChanged()` reads this list and enqueues them to the worklist.

* `AnalysisState::onUpdate()` allows custom logic to enqueue more to the worklist. This is called by `DataFlowSolver::propagateIfChanged()`.

This cleanup diff consolidates the two into `AnalysisState::onUpdate()`. This way, `DataFlowSolver` does not need to know the detail about `AnalysisState::dependents`, and the logic of dependency management is entirely handled by `AnalysisState`.

Reviewed By: Mogball

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

Kind of an edge case.  When a MODULE FUNCTION or SUBROUTINE
interface is defined by a MODULE PROCEDURE in the same program
unit, ensure that the symbol table pointer in the parse tree is
updated to point to the SubprogramDetails symbol for the
interface, and not left pointing to what should soon become
a dead SubprogramNameDetails symbol.

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

Before, we checked and manifested attributes right in the IR. This was
bad as we modified the IR before the manifest stage. Now we can
add/remove/inspect attributes w/o going to the IR (except for the
initial query).

We had some custom manifest for assumption attributes but we use the
generic manifest logic. If we later decide to curb duplication (of
attributes on the call site and callee), we can do that at a single
location and for all attributes.

The test changes basically add known `llvm.assume` callee information to
the call sites.

We had some custom handling for existing MemoryEffects but we now move
it to the place we check other existing attributes before we manifest
new ones. If we later decide to curb duplication (of attributes on the
call site and callee), we can do that at a single location and for all
attributes.

The test changes basically add known `memory` callee information to the
call sites.

This patch should fix some data races when a python script (i.e. a
Scripted Process) has a nested call to another python script (i.e. a
OperatingSystem Plugin), which can cause concurrent writes to the python
lock count.

This patch also fixes a data race happening when resetting the operating
system unique pointer.

To address these issues, both accesses is guarded by a mutex.

rdar://109413039

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



Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

We always assume that this is valid anyway, might as well take a
reference.

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

OPEN statements can be used to change some, but not all, attributes
of units that have already been opened.  The I/O runtime library
wasn't allowing ENCODING= to be changed.  Every other Fortran compiler
permits this usage, and it's safe and useful, so allow it.
(Otherwise there's no good way to ensure that the preconnected
unit 6 is in UTF-8 mode.)

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

We intentionally process NAMELIST groups in a scope after having
resolved all of the names in that scope.  This means that a name
whose first appearance in a scope is in the NAMELIST group resolves
to a local object, if any, rather than to any host associated object.
The standard is unclear on this point, and there is no clear
precedent in other compilers.

This patch doesn't implement this choice -- that was done long ago --
but just documents the behavior in Extensions.md.

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

The code that folds the intrinsic function HYPOT was neglecting to
warn the programmer about overflow when it occurs.

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

We already have LLDB_DEPRECATED which is used to mark methods as
deprecated with a message and an alternative to use instead. This is
expresses an intent of "We recognize this functionality is useful but
there are some pitfalls with the interface we have exposed."

In other cases, there are no "alternative" methods to use and the code should be
refactored to avoid using a method entirely. For example,
`SBValue::Cast` should be avoided in favor of using the expression
evaluator to perform a cast. There isn't a mechanical solution, the
recommendation is to instead refactor your code.

This commit renames the existing `LLDB_DEPRECATED` to
`LLDB_DEPRECATED_FIXME`, and adds a `LLDB_DEPRECATED` macro to cover the
second scenario.

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

I'm not convinced that it makes sense for the paths to be ConstStrings. We're
going to be putting them into FileSpecs (which are backed by
ConstStrings, for now) but otherwise there's no need to store them as
ConstStrings upfront.

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

Based on @peixin test case shared in D153004.