Recently I had to use it and although one assumes it returns null if
there's no parent loop, I think it helps to doc it.

Reviewed By: Meinersbur

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

This reverts commit 0bb90628 since it is causing failures on the Windows LLDB buildbot:

http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/14048

This removes a couple useless includes and the dependency of X86Desc on Object,
which was useless as well.

To unblock the builders this disables a test for which the CHECK lines
need to be updated. The patch causing the failure was not reverted
because it is needed for a different problem we are investigating. Here
we just need to update the CHECK lines which will happen in the
meantime.

This patch adds a cache that is valid only for the duration of a call
to getKnownBits. With such short lived cache we avoid all the problems
of cache invalidation while still getting the benefits of reusing
the information we already computed.

This cache is useful whenever an instruction occurs more than once
in a chain of computation.
E.g.,
v0 = G_ADD v1, v2
v3 = G_ADD v0, v1

Previously we would compute the known bits for:
v1, v2, v0, then v1 again and finally v3.

With the patch, now we won't have to recompute v1 again.

NFC

The buildbot
  http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win
shows some strange SCC iterator bug since 16188f9d which we need to
investigate. This patch should remove the part of 16188f9d that could
have exposed the problem.

Summary:
Blocks in a loop can be in any order as long as the loop header is the
first block in Blocks.
With some order of Blocks, cloneLoopWithPreheader would trigger the
assertion in addBasicBlockToLoop.

Example:

define void @test(i64 %N) {
preheader.i:
  br label %header.i

header.i:
  %i = phi i64 [ 0, %preheader.i ], [ %inc.i, %latch.i ]
  br label %header.j

header.j:
  %j = phi i64 [ 0, %header.i ], [ %inc.j, %latch.j ]
  br label %header.k

header.k:
  %k = phi i64 [ 0, %header.j ], [ %inc.k, %latch.k ]
  call void @baz(i64 %i, i64 %j, i64 %k)
  br label %latch.k

latch.k:
  %inc.k = add nsw i64 %k, 1
  %cmp.k = icmp slt i64 %inc.k, %N
  br i1 %cmp.k, label %header.k, label %latch.j

latch.j:
  %inc.j = add nsw i64 %j, 1
  %cmp.j = icmp slt i64 %inc.j, %N
  br i1 %cmp.j, label %header.j, label %latch.i

latch.i:
  %inc.i = add nsw i64 %i, 1
  %cmp.i = icmp slt i64 %inc.i, %N
  br i1 %cmp.i, label %header.i, label %exit.i

exit.i:
  ret void
}
declare void @baz(i64, i64, i64)
If the blocks of loop-i is in the order: header.i, latch.k, header.k,
header.j, latch.j, latch.i,
then cloneLoopWithPreheader would trigger the assertion in
addBasicBlockToLoop
assert(contains(SameHeader) && getHeader() == SameHeader->getHeader() &&
"Incorrect LI specified for this loop!");

As latch.k is in both loop-j and loop-k, it would be set as the header
of both loops after adding latch.k.
If we update loop headers during cloning blocks, then after adding
header.k,
the header of loop-k would be updated with header.k,
while the header of loop-j stays as latch.k.

When adding header.j, SameHeader is loop-k, SameHeader->getHeader() is
header.k, but getHeader() is latch.k, which trigger the assertion.
Reviewer: jdoerfert, Meinersbur, fhahn, kbarton, hfinkel, bmahjour,
etiotto
Reviewed By: Meinersbur
Subscribers: hiraditya, llvm-commits
Tag: LLVM
Differential Revision: https://reviews.llvm.org/D74382

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

1874dee5 moved CPU_(SUB_)TYPE logic to
BinaryFormat. Object is not directly referenced.

[AArch64][SVE] Fix -DBUILD_SHARED_LIBS=on builds after -D74808/1874dee5

We want flag users to check individual fast-math flags,
not that all of them are set. This was also probably
not working as intended because NoFPExcept isn't always
set on non-strict nodes.

Follow-up to 20d51b2f, rename the setter to
make it consistent with the getter. Also fixed a few comments along the
way, didn't try to find all references to a module manager.

Reviewed By: dexonsmith

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

Currently, in macOS, when a process crashes, lldb halts inside the
implementation disassembly without yielding any useful information.
The only way to get more information is to detach from the process, then wait
for ReportCrash to generate a report, find the report, then see what error
message was included in it. Instead of waiting for this to happen, lldb could
locate the error_string and make it available to the user.

This patch addresses this issue by enabling the user to fetch extended
crash information for crashed processes using `process status --verbose`.

Depending on the platform, this will try to gather different crash information
into an structured data dictionnary. This dictionnary is generic and extensible,
as it contains an array for each different type of crash information.

On Darwin Platforms, lldb will iterate over each of the target's images,
extract their `__crash_info` section and generated a StructuredData::Array
containing, in each entry, the module spec, its UUID, the crash messages
and the abort cause. The array will be inserted into the platform's
`m_extended_crash_info` dictionnary and `FetchExtendedCrashInformation` will
return its JSON representation like this:

```
{
  "crash-info annotations": [
    {
      "abort-cause": 0,
      "image": "/usr/lib/system/libsystem_malloc.dylib",
      "message": "main(76483,0x1000cedc0) malloc: *** error for object 0x1003040a0: pointer being freed was not allocated",
      "message2": "",
      "uuid": "5747D0C9-900D-3306-8D70-1E2EA4B7E821"
    },
    ...
  ],
  ...
}
```

This crash information can also be fetched using the SB API or lldb-rpc protocol
using SBTarget::GetExtendedCrashInformation().

rdar://37736535

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

Since the `platform process` commamnd has more tests now, this commits
separates each of the `platform process` subcommand's test in its own directory.

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

In this diff we change the storage of a section to unique_ptr.
This refactoring was factored out from D71647.

Test plan: make check-all

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

Add support for DestructiveBinaryComm DestructiveInstType, as well as the lowering code to expand the new Pseudos into the final movprfx+instruction pairs.

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

Reviewers: arsenm

Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, rovka, dstuttard, tpr, t-tye, hiraditya, kerbowa, llvm-commits

Tags: #llvm

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

This should be the last step in the current cleanup.
Follow-ups should resolve the TODO about cost calc
and enable the more general case where we extract
different elements.

Summary:
This change allows a hard coded relative PYTHONHOME setting. So that
python can easily be packaged together with lldb.

The change includes:
1. Extend LLDB_RELOCATABLE_PYTHON to all platforms. It defaults to ON
for platforms other than Windows, to keep the behavior compatible.
2. Allows to customize LLDB_PYTHON_HOME. But still defaults to
PYTHON_HOME.
3. LLDB_PYTHON_HOME can be a path relative to liblldb. If it is
relative, we will resolve it before send it to Py_DecodeLocale.

Subscribers: mgorny, lldb-commits

Tags: #lldb

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

This moves all the logic of converting LLVM Triples to
MachO::CPU_(SUB_)TYPE from the specific target (Target)AsmBackend to
more convenient functions in lib/BinaryFormat.

This also gets rid of the separate two X86AsmBackend classes.

The previous attempt was to add it to libObject, but that adds an
unnecessary dependency to libObject from all the targets.

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

[X86] Add a new format type for instructions that represent named prefix bytes like data16 and rep. Use it to make a simpler version of isPrefix.

isPrefix was added to support the patches to align branches.
it relies on a switch over instruction names.

This moves those opcodes to a new format so the information is
tablegen and we can just check for a specific value in some bits
in TSFlags instead.

I've left the other function in place for now so that the
existing patches in phabricator will still work. I'll work with
the owner to get them migrated.

Pointed out by Jay Foad.

Summary: The patch covers both register/register and register/immediate addressing modes.

Reviewers: efriedma, andwar, sdesmalen

Reviewed By: sdesmalen

Subscribers: sdesmalen, tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, llvm-commits

Tags: #llvm

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

More cleanup is possible now, but we probably need to
resolve the TODO about the existing difference between
compares and binops.

Summary:
Added register + immediate and register + register addressing modes for the following intrinsics:

1. Masked load and stores:
     * Sign and zero extended load and truncated stores.
     * No extension or truncation.
2. Masked non-temporal load and store.

Reviewers: andwar, efriedma

Subscribers: cameron.mcinally, sdesmalen, tschuett, kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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

Summary:
NFC - Moved StandardOps/Ops.h to a StandardOps/IR dir to better match surrounding
directories. This is to match other dialects, and prepare for moving StandardOps
related transforms in out for Transforms and into StandardOps/Transforms.

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

When each byte in b&m is non-zero, this conversion Q->V->Q is a no-op.

Reviewed By: rriddle

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

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

By default the RISC-V target doesn't have the atomics standard extension
enabled. The first RUN line in `clang/test/CodeGen/atomic_ops.c` didn't
specify a target triple, which meant that on RISC-V Linux hosts it would
target RISC-V, but because it used clang cc1 we didn't get the toolchain
driver functionality to automatically turn on the extensions implied by
the target triple (riscv64-linux includes atomics). This would cause the
test to fail on RISC-V hosts.

This patch changes the test to have RUN lines for two explicit targets,
one with native atomics and one without. To work around FileCheck
limitations and more accurately match the output, some tests now have
separate prefixes for the two cases.

Reviewers: jyknight, eli.friedman, lenary, efriedma
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D74847

This patch adds backend support for splats of both Int and FP immediates.

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

Otherwise, the `availability=XXX` lit feature is set even when we're
testing trunk and _LIBCPP_DISABLE_AVAILABILITY is defined, which causes
tests that check for availability markup to be enabled and unexpectedly
pass.

The legalizer helper functions are unusably awkward to perform the 3-5
part legalization. This needs to be widened, scalarized, lowered, and
we should avoid creating vector extends and truncates. Manually do all
of this and expand.

Summary:
The purpose of this patch is to make identifying missing dependencies clearer to the user.
`find_package` will report if a package is not found, that output, combined with the exiting
status message, is clearer than not having the additional verbosity.

If the SWIG dependency is required {LLDB_ENABLE_PYTHON, LLDB_ENABLE_LUA}
and SWIG is not available, fail the configuration step.  Terminate the
configure early rather than later with a clear error message.

We could possibly modify:
`llvm-project/lldb/cmake/modules/FindPythonInterpAndLibs.cmake`
However, the patch here seems clear in my opinion.

Reviewers: aadsm, hhb, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: labath, jrm, mgorny, lldb-commits

Tags: #lldb

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

I tried to use some of the new tablegen features to avoid creating
different operand list permutations, but I still don't see a way to
programmatically build a source pattern dag.

Also add GlobalISel tests, which now all import successfully.

Some of the fneg fold tests are incorrect, which need to be fixed in a
future commit

I'm slighly worried about the generated checks, since they won't catch
incorrect modifiers being added at the end of the line.

This only handles the basic cases. More work is needed to make better
use of op_sel.