The existing code makes it hard to tell that collectStridedAccess is really about identifying some loop invariant SCEV which is *profitable* to speculate is equal to one. The odd dual usage structure of Value and SCEV confuses this point.

We could choose to loosen the profitability analysis if desired. I'm not proposing doing so at this time as it exposes too many cases where the speculation is unprofitable.

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

On Windows, global string literals with "linkonce" linkage is not
supported without using comdat. As a simpler fix than adding comdat
support we can use internal linkage instead.

This fixes a bug where two string literals with the same value in
different fortran files would cause a linker error due to the use
of linkonce linkage.

Reviewed By: jeanPerier

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

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

This commit implements the serialization and deserialization of the Machine
Function's EntryValueObjects.

Depends on D149879, D149778

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

I forgot that we still used these variables in the loaders.

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

This fixes the visualizers for:
Type
DeclContext
QualType
TypedefNameDecl
NestedNameSpecifier
FunctionDecl

and adds visualizers for:
VariableArrayType
ElaboratedType
ParenType
BitIntType

This fixes the visualizers for:
PointerIntPair
PointerUnion
PointerIntPair<PointerUnion<*>, *>
StringMapEntry

and adds a visualizer for:
PunnedPointer

Small cleanup of the server code and fixes a constant name not following
the naming convention.

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

Fixes #60778.

When instantiating the body of a class template specialization that was
instantiated from a partial specialization, we were incorrectly
collecting template arguments from the primary template, which resulted
in the template arguments list being inaccurate.  In the example from
the issue, we were trying to substitute the boolean 'false' into the
type on Nested, which caused an assertion.

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

Improve the constant import to handle zeroinitializer as well as
additional float types such as quad floats. The logic got restructured
to avoid creating intermediate dense element attributes when
constructing multi-dimensional arrays. Additionally, we also leverage
the fact that we do not need to iterate all elements of splat constants.

Reviewed By: Dinistro

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

This revision uses contains in favor of count when
searching sets and maps. Additionally it uses find
instead of count and lookup, which avoids searching
some maps twice.

Reviewed By: Dinistro

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

Land D42600 with optimisation disabled by default by setting 'enable-shrink-wrap-region-split' option.

This is just to reduce effort involved in making changes to patch each time issue is detected and reland the whole patch.

We were querying the wrong EncReader along some paths that resulted in
failures depending on if one encountered an Attribute from an unloaded
dialect before encountering an operation from that dialect.

Also fix error where we were able to emit "custom" form for an attribute
without custom form in TestDialect.

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

Currently complex division is lowered to a fir.divc operation and the
fir.divc is later converted to a sequence of llvm operations to perform
complex division, however this causes issues for extreme values when
the calculations overflow.

This patch changes the lowering of complex division to use the Intrinsic
Call functionality to lower into library calls (for single, double,
extended and quad precisions) or an MLIR complex dialect division operation
(for half and bfloat precisions).

 A new wrapper function `genLibSplitComplexArgsCall` is written to handle
 the case of the arguments of the Complex Library calls being split to
its real and imaginary real components.

Note 1: If the Complex To Standard conversion of division operation
matures then we can use it for all precisions. Currently it has the
same issues as the conversion of fir.divc.
Note 2: A previous patch (D145808) did the same but during conversion of
the fir.divc operation. But using function calls at that stage leads to
ABI issues since the conversion to LLVM is not aware of the complex target
rewrite.
Note 3: If the patch is accepted, fir.divc can be removed from FIR. We
can use the complex.div operation where any transformation is required.

Reviewed By: vzakhari, PeteSteinfeld, DavidTruby, jeanPerier

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

MachineFunction keeps a table of variables whose addresses never change
throughout the function. Today, the only kinds of locations it can
handle are stack slots.

However, we could expand this for variables whose address is derived
from the value a register had upon function entry. One case where this
happens is with variables alive across coroutine funclets: these can
be placed in a coroutine frame object whose pointer is placed in a
register that is an argument to coroutine funclets.

```
define @foo(ptr %frame_ptr) {
  dbg.declare(%frame_ptr, !some_var,
              !DIExpression(EntryValue, <ptr_arithmetic>))
```

This is a patch in a series that aims to improve the debug information
generated by the CoroSplit pass in the context of `swiftasync`
arguments. Variables stored in the coroutine frame _must_ be described
the entry_value of the ABI-defined register containing a pointer to the
coroutine frame. Since these variables have a single location throughout
their lifetime, they are candidates for being stored in the
MachineFunction table.

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

Several tests undefined __DEPRECATED to avoid warnings as they're
testing the deprecated ext/hash_map. A better way to do this is to use
-Wno-deprecated so it isn't defined in the first place. This prevents
these tests from failing when we give a warning when undefining the
__DEPRECATED macro, as D144654 will do.

For the generated tests however just remove the testing of these
header files, so we don't disable the warning when testing the other
header files.

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

When we lower BUILD_VECTOR to VECTOR_SHUFFL, we could generate efficient vector
mask. For example,

 t24: v8i8 = BUILD_VECTOR t25, t25, t25, t25, t26, t26, t26, t26
 ==>
   t27: v8i8 = BUILD_VECTOR t26, t26, t26, t26, t26, t26, t26, t26
   t28: v8i8 = BUILD_VECTOR t25, t25, t25, t25, t25, t25, t25, t25
 t29: v8i8 = vector_shuffle<0,1,2,3,12,13,14,15> t27, t2

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

Being able to link statically depends on other CMake options and choice of libc.

This patch makes sure:
 - we pass the correct compiler options when building Google benchmarks,
 - we only import the C++ version of the memory functions.

The change in libc/cmake/modules/LLVMLibCTestRules.cmake is here to make sure CMake can generate the right command line in the presence of the CMAKE_CROSSCOMPILING_EMULATOR option.

Relevant documentation:
https://cmake.org/cmake/help/latest/variable/CMAKE_CROSSCOMPILING_EMULATOR.html
https://cmake.org/cmake/help/latest/command/add_custom_command.html#command:add_custom_command
"
If COMMAND specifies an executable target name (created by the `add_executable()` command), it will automatically be replaced by the location of the executable created at build time if either of the following is true:
 - The target is not being cross-compiled (i.e. the CMAKE_CROSSCOMPILING variable is not set to true).
 - New in version 3.6: The target is being cross-compiled and an emulator is provided (i.e. its CROSSCOMPILING_EMULATOR target property is set). In this case, the contents of CROSSCOMPILING_EMULATOR will be prepended to the command before the location of the target executable.
"

Reviewed By: gchatelet

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

According to the EBNF syntax described in the 'Common syntax' chapter,
literal characters should be surrounded by backticks (`). However, in
some sections of this document, single quotes (') are used instead.
So, fix them.

Reviewed By: mehdi_amini

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

Reviewed By: e-kud
Differential Revision: https://reviews.llvm.org/D149844

Add support for splitting critical edges coming from an indirect jump
using a jump table ("switch jumps").

This introduces the `TargetInstrInfo::getJumpTableIndex` callback to
allows targets to return an index into `MachineJumpTableInfo` for a
given indirect jump. It also updates to
`MachineBasicBlock::SplitCriticalEdge` to allow splitting of critical
edges by rewriting jump table entries.

This is largely based on work done by Zhixuan Huan in D132202.

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

If we're using an old instrprof profile and the user passes we can get
Decls with children decl counts not matching the what the profile was
written against. In a particular case I was debugging we have 24 decls
in the AST and 22 decls in the profile. Avoid crashing in this case.

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

After enhancement for XCOFF integrated assembler mode, now OrcCAPITest
can be enabled on AIX.

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

Close https://github.com/llvm/llvm-project/issues/62174

And this was originally a try to close
https://github.com/llvm/llvm-project/issues/62158.

I don't feel this is the correct fix. I just think it is not bad as an
ad-hoc patch. And let's discuss things in the higher-level in the above
GitHub issue link.

Reviewed By: erichkeane

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

Allows moving the pointer swap between server and client into reset.
Single allocation simplifies whatever allocates the client/server, currently
the libc loaders.

Reviewed By: jhuber6

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

Removes an empty file inadvertently included with
b8d2f717.

The information is not tied to tensor.empty op and tensor.extract_slice
op. We can infer smallest static bounding box for pad transform if
they implement ReifyRankedShapedTypeOpInterface. The revision extends
the usability for downstream projects. No tests are added because the
existing tests cover the change, and most of MLIR
ReifyRankedShapedTypeOpInterface ops are covered in the tests, except
tensor.generate and bufferization.alloc_tensor ops.

Reviewed By: mravishankar

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

[OpenMP][Flang][Semantics] Add semantics support for USE_DEVICE_ADDR clause on OMP TARGET DATA directive.

Reviewed By: kiranchandramohan

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

Swift and ObjC testcases require a jit-compatible runtime.

rdar://109162598

The interface exported by the RPC library allows users to simply send
and recieve fixed sized packets without worrying about the data motion
underneath. However, this was broken in the current implementation. We
can think of the send and recieve implementations in terms of waiting
for ownership of the buffer, using the buffer, and posting ownership to
the other side. Our implementation of `recv` was incorrect in the
following scenarios.

recv -> send // we still own the buffer and should give away ownership
recv -> close // The other side is not waiting for data, this will
                 result in multiple openings of the same port

This patch attempts to fix this with an admittedly hacky fix where we
track if the previous implementation was a recv and post conditionally.

Reviewed By: JonChesterfield

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

lldb needs to find the virtual address of the mach header of a
binary.  It first scans for a segment which starts at file offset
0, and uses the vmaddr of that segment.  If no segment starts at
fileoff 0, it looks for a segment named __TEXT.

This patch changes the order of those, to first search for the TEXT
segment.  We have a situation where binaries exist that have the
DATA segment first, which does not have the vmaddr of the mach header,
it merely happens to come first in the binary file.  It's an unusual
arrangement, but not breaking any rules of Mach-O.  So lldb needs
to handle this.

Differential Revision: https://reviews.llvm.org/D150239
rdar://109128418

Replaces the globals currently used. Worth changing to a bitmap
before allowing runtime number of ports >> 64. One bit per port is likely
to be cheap enough that sizing for the worst case is always fine, otherwise
in the future we can change to dynamically allocating it.

Reviewed By: jhuber6

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

I was seeing a regression when enabling FS discriminators on an non-FS CSSPGO build. This is because a probe can get a zero-valued discriminator at a specific pass and that could lead to accidentally loading the corresponding base counter in the non-FS profile, while a non-zeo discriminator would end up getting zero samples. This could in turn undo the sample distribution effort done by previous BFI maintenance work and the probe distribution factor work for pseudo probes specifically. To mitigate that I'm disabling loading a non-FS profile against FS discriminators. The problem should also exist with non-CS AutoFDO, so I'm doing this for it too.

Reviewed By: wenlei

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

The Port type has stipuations that the same exact mask used to open it
needs to close it. This can currently be violated by calling its move
constructor to put it somewhere else. We still need the move constructor
to handle the open and closing functions. So, we simply make these
constructors private and only allow a few classes to have move
priviledges on it.

Reviewed By: JonChesterfield, lntue

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

This is part of an on-going migration to adopt Properties inside MLIR.

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

This is part of an on-going migration to adopt Properties inside MLIR.

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

This is part of an on-going migration to adopt Properties inside MLIR.

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

This is part of an on-going migration to adopt Properties inside MLIR.

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