This patch adds lowering for task construct from Fortran to
`omp.task` operation in OpenMPDialect Dialect (mlir). Also added tests
for the same.

Reviewed By: kiranchandramohan, peixin

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

llvm's json parser supports uint64_t, so let's better use it for the
packets being sent between lldb and lldb-server instead of using int64_t
as an intermediate type, which might be error-prone.

Even if the minimum number of elements is 1 and the length doesn't change,
we don't know what vscale is so we can't classify it as identity mask. Instead it
is a zero element splat.

For reverse, we shouldn't classify it as a reverse unless there are at least 2 elements
in the mask. This applies to both fixed and scalable vectors. For fixed vectors, a single
element would be an identity shuffle. For scalable vector it's a zero elt splat.

Reviewed By: sdesmalen, liaolucy

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

    It turns out that the issue in
    https://lab.llvm.org/buildbot/#/builders/17/builds/21754 is that a
    size_t is attempted to be used interchangeably with uint64_t.

It turns out that the issue in
https://lab.llvm.org/buildbot/#/builders/17/builds/21754 is that a
size_t is attempted to be used interchangeably with uint64_t.

This commit causes
https://lab.llvm.org/buildbot/#/builders/17/builds/21743 to fail
seemingly because of bad handling of the PERF_ATTR_SIZE_VER5 symbol.

This patch tries to handle better the absence of this symbol.

[IRSim] Remove early check from similarity matching such that commutative instructions are checked correctly when using the same value.

When the first commutative instruction in a region using the same value in both positions was compared to a corresponding instruction with two different values, there was an early check that determined that since the values were new, it was true that these values acted in the same way structurally. If this was not contradicted later in the program, the regions were marked as similar. This removes that check, so that it is clear that the same value cannot be mapped to two different values.

Reviewer: paquette

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

Currently, building mlir with the python bindings enabled on Windows in Debug is broken because pybind11, python and cmake don't like to play together. This change normalizes how the three interact, so that the builds can now run and succeed.

The main issue is that python and cmake both make assumptions about which libraries are needed in a Windows build based on the flavor.
- cmake assumes that a debug (or a debug-like) flavor of the build will always require pythonX_d.lib and provides no option/hint to tell it to use a different library. cmake does find both the debug and release versions, but then uses the debug library.
- python (specifically pyconfig.h and by extension python.h) hardcodes the dependency on pythonX_d.lib or pythonX.lib depending on whether `_DEBUG` is defined. This is NOT transparent - it does not show up anywhere in the build logs until the link step fails with `pythonX_d.lib is missing` (or `pythonX.lib is missing`)
- pybind11 tr...

Reviewed By: benshi001

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

Reviewed By: craig.topper

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

In a function, ENTRY E without an explicit RESULT() creates a
function result entity also named E that is storage associated with
the enclosing function's result.  f18 was emitting an incorrect error
message if that function result E was referenced without any
declaration prior to its ENTRY statement when it should have been
implicitly declared instead.

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

Reviewed By: iains

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

As is already supported for dummy procedures, we need to also accept
declarations of procedure pointers that consist of a POINTER attribute
statement followed by an INTERFACE block.  (The case of an INTERFACE
block followed by a POINTER statement already works.)

While cleaning this case up, adjust the utility predicate IsProcedurePointer()
to recognize it (namely a SubprogramDetails symbol with Attr::POINTER)
and delete IsProcName().  Extend tests, and add better comments to
symbol.h to document the two ways in which procedure pointers are
represented.

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

This allows the compiler to support more features than those supported by a
model. The only requirement (development mode only) is that the new
features must be appended at the end of the list of features requested
from the model. The support is transparent to compiler code: for
unsupported features, we provide a valid buffer to copy their values;
it's just that this buffer is disconnected from the model, so insofar
as the model is concerned (AOT or development mode), these features don't
exist. The buffers are allocated at setup - meaning, at steady state,
there is no extra allocation (maintaining the current invariant). These
buffers has 2 roles: one, keep the compiler code simple. Second, allow
logging their values in development mode. The latter allows retraining
a model supporting the larger feature set starting from traces produced
with the old model.

For release mode (AOT-ed models), this decouples compiler evolution from
model e...

The semantic test for an intrinsic assignment to a polymorphic
derived type entity from a type that is an extension of its base
type was reversed, so it would allow assignments that it shouldn't
and disallowed some that it should; and the test case for it
incorectly assumed that the invalid semantics were correct.
Fix the code and the test, and add a new test for the invalid
case (LHS type is an extension of the RHS type).

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

The rules in the Fortran standard for specification expressions
are full of special cases and exceptions, and semantics didn't get
them exactly right.  It is valid to refer to an INTENT(OUT) dummy
argument in a specification expression in the context of a
specification inquiry function like SIZE(); it is not valid to
reference an OPTIONAL dummy argument outside of the context of
PRESENT.  This patch makes the specification expression checker
a little context-sensitive about whether it's examining an actual
argument of a specification inquiry intrinsic function or not.

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

DATA statements in inner procedures were not treating undeclared objects
as implicitly declared variables if the DATA statement appeared in a
specification part; they were treated as host-associated symbols instead.
This was incorrect.  Fix DATA statement name resolution to always treat
DATA as if it had appeared in the executable part.

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

A disassociated procedure pointer is allowed to be passed as an absent
actual argument that corresponds to an optional dummy procedure,
but not NULL(); accept that case as well.

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

The type compatibility checks for the ARRAY= argument and the dummy
arguments and result of the OPERATION= argument to the REDUCE intrinsic
function need to allow for parameterized data types with LEN parameters.
(Their values are required to be identical but this is not a numbered
constraint requiring a compilation time check).

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

This cleans up tech debt. Similar to D33390 .

Reviewed By: Kmeakin

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

Functions returning ALLOCATABLE or POINTER arrays have descriptor inquiries in
their results' shape expressions that won't compare equal.  These functions
need only be checked for compatible ranks (& of course other characteristics).

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

The utility UnwrapConvertedExpr() was failing to unwrap a
converted TypeParamInquiry operation when called from runtime
derived type description table construction, leading to an
abort in semantics.

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

Structure contructors for instances of parameterized derived types
must have their components' values folded in the context of the values
of the type parameters.

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

A previous commit enabled LLDB to be able to debug a program launched via ld: https://reviews.llvm.org/D108061.

This commit adds the ability to debug a program launched via ld when it happens during an exec into the dynamic loader. There was an issue where after the exec we would locate the rendezvous structure right away but it didn't contain any valid values and we would try to set the dyanamic loader breakpoint at address zero. This patch fixes that and adds a test.

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

I'm refactoring IntelPTThreadTrace into IntelPTSingleBufferTrace so that it can
both single threads or single cores. In this diff I'm basically renaming the
class, moving it to its own file, and removing all the pieces that are not used
along with some basic cleanup.

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

This updates the documentation of the gdb-remote protocol, as well as the help messages, to include the new --per-core-tracing option.

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

Merge the documentation of the definition of extensible dialects
with the definition of dialects.

Reviewed By: rriddle

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

Actual arguments whose lengths are less than the expected length
of their corresponding dummy argument are errors; but this needs
to be refined.  Short actual arguments that are variables remain
errors, but those that are expressions can be (again) extended on
the right with blanks.

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

This prevents races where we accidentally launched multiple servers.

The construction of the dimension order vector used to populate the
result array was incorrect, leading to a scrambled-looking result
for rank-3 and higher results.  Fix, and extend tests.

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

When a callee function is inlined via an invoke instruction, every function call inside the callee, if not an invoke,  will be converted to an invoke after cloned to the caller body. I found that during the conversion the !prof metadata was dropped. This in turned caused a cloned indirect call not properly promoted in subsequent passes.

The particular scenario I was investigating was with AutoFDO and thinLTO. In prelink, no ICP was triggered (neither by the sample loader nor PGO ICP), no indirect call was promoted. This is because 1) the particular indirect call did not have inlined samples;  and 2) PGO ICP was intentionally disabled.  After inlining, the prof metadata was dropped. Then in postlink, PGO ICP jumped in but didn't do anything. Thus the opportunity was missed.

I'm making a simple fix to preserve !prof metadata when converting call to invoke.

Reviewed By: davidxl

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