This reverts commit 18f1c1ac and fix the
build failure issues introduced because of the `STRING_EXTENSION_OUTSIDE`
swig macros.

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



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

[flang] Better error recovery when using erroneous procedures and pointers as intrinsic actual arguments

Instead of crashing with an internal error when a procedure or
procedure pointer with a badly declared interface is presented to
an intrinsic procedure like ASSOCIATED, emit an error message
and continue with compilation.

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

The printing of `StringAttr` was changed in
https://reviews.llvm.org/D158974, such that some test cases relying on
that output had to be changed as well.

The utility semantics::SemanticsContext::FindScope() maps a contiguous
range of cooked source characters to the innermost Scope containing
them.  Its implementation is unacceptably slow on large (tens of
thousands of lines) source files with many program units; it traverses
each level of the scope tree linearly.

Replace this implementation with a single instance of std::multimap<>
used as an index from each Scope's source range back to the Scope.

Compilation time with "-fsyntax-only" on the 50,000-line test case
that motivated this change drops from 4.36s to 3.72s, and FindScope()
no longer stands out egregiously in the profile.

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

An outdated comment was removed from the expected output,
but not the actual test file.

This patch makes the `transform.structured.pad` op return also a handle
to the copy op that it inserts. This allows to continue transformation
on that op, such as mapping it to a GPU thread.

The patch was mainly authored by @springerm as part of the WIP patch
https://reviews.llvm.org/D156371, which also has an example usage of
this change.

Reviewed By: nicolasvasilache

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

This allows to use Python's `bool(.)`, `float(.)`, `int(.)`, and
`str(.)` to convert pybound attributes to the corresponding native
Python types. In particular, pybind11 uses these functions to
automatically cast objects to the corresponding primitive types wherever
they are required by pybound functions, e.g., arguments are converted to
Python's `int` if the C++ signature requires a C++ `int`. With this
patch, pybound attributes can by used wherever the corresponding native
types are expected. New tests show-case this behavior in the
constructors of `Dense*ArrayAttr`.

Note that this changes the output of Python's `str` on `StringAttr` from
`"hello"` to `hello`. Arguably, this is still in line with `str`s goal
of producing a readable interpretation of the value, even if it is now
not unambiously a string anymore (`print(ir.Attribute.parse('"42"'))`
now outputs `42`). However, this is consistent with instances of
Python's `str` (`print("42")` outputs `42`), and `repr` still provides
an unambigous representation if one is required.

Reviewed By: springerm

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

The current code can crash due to the representation's use of a negative
INTEGER kind code to signify a typeless (BOZ) argument's "type" as a
DynamicType.  Detect and handle that case, and change some direct
uses of the kind_ data member into kind() accessor references in
places that shouldn't be confronted with BOZ.

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

This patch shares the logic between the various splat ComplexPatterns to help
the diff in some upcoming patches.

It's worth noting that the uimm splat pattern now takes into account the
implicit truncation + sign extend semantics of vmv_v_x_vl, but that doesn't
seem to affect the result since it always took the sext value anyway.

Reviewed By: craig.topper

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

If the function argument block contains patterns, we split argument
matching into a separate SAME line, because LABEL labels may not contain
pattern matches.

Until now, in this case we moved the parenthesis opening the argument block
into the second line.

This generates incorrect labels in case function names are not prefix-free.

For example, for a function `foo` we generated:

   CHECK-LABEL: foo
   CHECK-SAME: (<args of foo>)

If the output also contains a function `foo.specialzied`, then the label for
`foo` can match `foo.specialized`, depending on output order.

This patch moves opening parenthesis to the first line, breaking common prefixes:

   CHECK-LABEL: foo(
   CHECK-SAME: <args of foo>)

Bump the UTC version to 3, and only move the parenthesis for version 3 and later.

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

Review of the actual change: https://reviews.llvm.org/D158497

Split widenCondCommon into mergeChecks and hoistChecks methods for
better logic isolation.

Reviewed By: anna

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

The flag "anyIntrinsicDefinedOps" is always set nowadays, as there are intrinsic
modules that define operator(==) and (!=).  This disables the iterative
expression analysis mechanism, also unnecessarily, and it is possible to
overflow the stack when analyzing very deep expression trees like the ones
that show up in artificial stress tests.  Remove the flag.

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

Currently, clang does not resolve certain overloaded functions correctly in the initializer
of global variables, e.g.

template<typename T1, typename U>
T1 mypow(T1, U);

__attribute__((device)) double mypow(double, int);

double t_extent = mypow(1.0, 2);

In the above example, mypow is supposed to resolve to the host version
but clang resolves it to the device version instead, and emits an error
(https://godbolt.org/z/17xxzaa67).

However, if the variable is assigned in a host function, there is no error.
The discrepancy in overloading resolution inside and outside of
a function is due to clang not accounting for the host/device target
when resolving functions called in the initializer of a global variable.

This patch introduces a global host/device target context for CUDA/HIP
for functions called outside of functions. For global variable initialization,
it is determined by the host/device attribute of the variable. For other
situatio...

Fix the lowering of tosa.cast to create attributes of the input source
type when casting from floats to integers.

This is motivated by the need to cast fp16 to i9, which we have
encountered in certain quantized models.

Reviewed By: eric-k256, jpienaar

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

This adds an error if variable with incomplete type has initializer with
incomplete type, so it is not possible to deduce array size from
initializer.

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

Reviewed By: aaron.ballman, shafik

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

This reverts commit 2916b125.

Reverting due to failures on:
https://lab.llvm.org/buildbot/#/builders/216/builds/26407
https://lab.llvm.org/staging/#/builders/247/builds/5659
http://45.33.8.238/win/83485/step_7.txt

[X86] combineConcatVectorOps - support concatenation of 128->256-bit X86ISD::PCMPEQ/PCMPGT nodes on AVX2+ targets

Only bother if one of the ops is free to concat (most likely compare with constant).

Use an enum to clarify the type of fact or check in FactOrCheck, as
suggested in D158837.

If we're splatting the original subvector width then just use the original X86ISD::SUBV_BROADCAST_LOAD node - similar to what we're already doing with X86ISD::VBROADCAST/VBROADCAST_LOAD

This reverts commit 498b59e0 since it
introduces a build failure:

https://lab.llvm.org/buildbot/#/builders/68/builds/58995



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

This differs from the positive case in that shifting by a larger
amount makes the result smaller, not larger.

This patch does various things to silence the warnings that show up when
generating the website documentation.

First, this patch adds the missing definition for special member methods
in every SBAPI class. If the class cannot implement one of the special
member method, we just define it as a null operation (pass).

This should fix the following warnings:

```
WARNING: missing attribute __int__ in object lldb.SB*
WARNING: missing attribute __len__ in object lldb.SB*
WARNING: missing attribute __hex__ in object lldb.SB*
WARNING: missing attribute __oct__ in object lldb.SB*
WARNING: missing attribute __iter__ in object lldb.SB*
```

Then, it un-skips the various `static` methods that we didn't generate
the methods for, since it's not necessary thanks to the automod-api module.

Finally, this comments out the `_static` directory in the sphinx config,
since we don't need it anymore.

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



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

When SVE2 is enabled, we can combine an add of 1, add & shift right by 1
to a single s/urhadd instruction. If the operands to the adds are extended,
these extends will fold into the s/urhadd and their costs should be 0.

Reviewed By: david-arm, dtemirbulatov

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

Implement LWG3464 https://wg21.link/LWG3464

Reviewed By: #libc, Mordante, philnik

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

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

Update DeviceRTL and the AMDGPU plugin to support code
object version 5. Default is code object version 4.

CodeGen for __builtin_amdgpu_workgroup_size generates code
for cov4 as well as cov5 if -mcode-object-version=none
is specified. DeviceRTL compilation passes this argument
via Xclang option to generate abi-agnostic code.

Generated code for the above builtin uses a clang
control constant "llvm.amdgcn.abi.version" to branch on
the abi version, which is available during linking of
user's OpenMP code. Load of this constant gets eliminated
during linking.

AMDGPU plugin queries the ELF for code object version
and then prepares various implicitargs accordingly.

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

Reviewed By: jhuber6, yaxunl

Split off from D150398 to avoid builder-related diff changes there.
Using IRBuilder to create ICmps simplifies the result if both operands
are constants.

Reviewed By: Ayal

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

This reverts commit e0f9cc71.
Differential Revision: https://reviews.llvm.org/D155406

Make sure complexity-based canonicalization doesn't get in the
way.

https://reviews.llvm.org/D157151 and https://reviews.llvm.org/D157837
added visibility flags to flang options, hiding options which are
supported only in Clang and not in Flang.

After this change, some negative flags e.g. `-fno-reciprocal-math` no
longer work with flang. These flags are supported in flang (as can be
seen from the support for the positive flags).

I also opted to make sure the clang visibility is the same on these
flags, although I did not look at changing the visibility of non-flang
flags.

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

This patch adds the first integration test for ArmSME in Linalg. It
fills a 2-d scalable vector that represents an SME ZA tile with a
pre-defined f32 value and prints it to stdout.

This test is predicated on the MLIR_RUN_ARM_SME_TESTS configuration flag
being set to true.

Depends on D158586

Reviewed By: awarzynski

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

MSVC defines __declspec(noalias) as follows (https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2012/k649tyc7(v=vs.110)?redirectedfrom=MSDN):

> noalias means that a function call does not modify or reference
> visible global state and only modifies the memory pointed to
> directly by pointer parameters (first-level indirections).

> If a function is annotated as noalias, the optimizer can assume
> that, in addition to the parameters themselves, only first-level
> indirections of pointer parameters are referenced or modified
> inside the function. The visible global state is the set of all
> data that is not defined or referenced outside of the compilation
> scope, and their address is not taken. The compilation scope is
> all source files (/LTCG (Link-time Code Generation) builds) or a
> single source file (non-/LTCG build).

The wording is not super clear to me, but I believe this is saying
that __declspec(noalias) functions may access inaccessible memory
(i.e. non-visible global state in their words). Indeed, the Windows
CRT applies this attribute to malloc, which does access inaccessible
memory under LLVM's memory model.

As such, change the attribute to emit
memory(argmem: readwrite, inaccessiblemem: readwrite) instead of
memory(argmem: readwrite).

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

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

This adds support for lowering vector.broadcast ops to SME, if the
source is either a scalar, 0-d vector, or 1-d vector, and the result a
2-d scalable vector that aligns with SME tiles.

This follows on from D157005 which introduced a vector to tile slice op
that moves a 1-d scalable vector to a slice of a 2-d scalable vector
(tile). The lowering from vector.broadcast is similar, a couple of
helper functions are added to prevent duplication.

Lowering of vector.broadcast contributes towards a path from linalg.fill
to SME.

Depends on D157005

Reviewed By: awarzynski, dcaballe

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

When clang generates an nrvo boolean flag, the dbg.declare for the
corresponding variable was incorrectly placed on that flag, rather
than the actual variable.

Fix this by not overwriting AllocaAddr with the nrvo flag.

This started causing verifier errors with D158743.

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

This adds a 'move_vector_to_tile_slice' op to the ArmSME dialect that
moves a 1-D scalable vector to a slice of a 2-D tile at a given index.

This is lowered to the 'llvm.aarch64.sme.write.horiz' intrinsic that
maps to the MOVA (vector to tile, single) SME instruction [1] when
lowering to LLVM. Like the SME load and store instructions this operates
on ZA tile slices, which are 1D vectors of horizontally or vertically
contiguous elements within a ZA tile.

This patch extends the lowering of 'arith.constant' to SME to support
non-zero constants using this new op.  This requires materializing a
loop that broadcasts the constant to each tile slice with the
'vector_to_tile_slice' op. Unlike load and store, this is done during
conversion from Vector to ArmSME, rather than ArmSME to SCF. The latter
would require a higher-level custom op in the ArmSME dialect like
'tile_load' and 'tile_store' and this isn't necessary. We may also
remove the load and store ops in the future in favour of lowering
straight from Vector, at which point this would converge.

Currently only horizontal tile slices are supported. A future patch will
extend this mechanism to support 'vector.broadcast'.

Depends on D156980 D157004

[1] https://developer.arm.com/documentation/ddi0602

Reviewed By: awarzynski, dcaballe

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