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

It's better to do the ands, shifts, ors in the vector domain than
to scalarize it and do those operations on each element.

Reviewed By: RKSimon

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

When we escape strings for C++, make sure we use C++ escape
sequences. (In particular, \x22 instead of \22)

Reviewed By: Mogball

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

Handle contraction op like all the other generic op reductions. This
simpifies the code. We now rely on contractionOp canonicalization to
keep the same code quality.

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

add several patterns that will simplify contraction vectorization in the
future. With those canonicalizationns we will be able to remove the special
case for contration during vectorization and rely on those transformations to
avoid materizalizing broadcast ops.

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

G_ICMP is selected to an arithmetic overflow op (ADDS/SUBS/etc) with a dead
destination + a CSINC instruction.

We have a fold which allows us to combine 32-bit adds with G_ICMP.

The problem with G_ICMP is that we model it as always having a 32-bit
destination even though it can be a 64-bit operation. So, we were missing some
opportunities for 64-bit folds.

This patch teaches the fold to recognize 64-bit G_ICMPs + refactors some of
the code surrounding CSINC accordingly.

(Later down the line, I think we should probably change the way we handle G_ICMP
in general.)

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

This test is makeing one buildbot fail for unknown reason. Remove
it until we can investifate further.

This issue only occurs when linked statically in MinGW configurations,
and has been fixed for Clang 14 by https://reviews.llvm.org/D109651.

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

MinGW headers/libs lack timespec_get.

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

The pattern became optimized after b92412fb.

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

This patch is a smaller version of a previous patch https://reviews.llvm.org/D110804.

This patch modifies the output of "statistics dump" to be able to get stats from the current target. It adds 3 new stats as well. The output of "statistics dump" is now emitted as JSON so that it can be used to track performance and statistics and the output could be used to populate a database that tracks performance. Sample output looks like:

(lldb) statistics dump
{
  "expressionEvaluation": {
    "failures": 0,
    "successes": 0
  },
  "firstStopTime": 0.34164492800000001,
  "frameVariable": {
    "failures": 0,
    "successes": 0
  },
  "launchOrAttachTime": 0.31969605400000001,
  "targetCreateTime": 0.0040863039999999998
}

The top level keys are:

"expressionEvaluation" which replaces the previous stats that were emitted as plain text. This dictionary contains the success and fail counts.
"frameVariable" which replaces the previous stats for "frame variable" that were emitted as plain text. This dictionary contains the success and fail counts.
"targetCreateTime" contains the number of seconds it took to create the target and load dependent libraries (if they were enabled) and also will contain symbol preloading times if that setting is enabled.
"launchOrAttachTime" is the time it takes from when the launch/attach is initiated to when the first private stop occurs.
"firstStopTime" is the time in seconds that it takes to stop at the first stop that is presented to the user via the LLDB interface. This value will only have meaning if you set a known breakpoint or stop location in your code that you want to measure as a performance test.

This diff is also meant as a place to discuess what we want out of the "statistics dump" command before adding more funcionality. It is also meant to clean up the previous code that was storting statistics in a vector of numbers within the lldb_private::Target class.

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

If a typedef type has __attribute__((btf_decl_tag("str"))) with
bpf target, emit BTF_KIND_DECL_TAG for that type in the BTF.

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

With the old approach we were updating `ObjCInterfaceType.Decl` to the
last encountered definition. But during loading modules
`ASTDeclReader::VisitObjCInterfaceDecl` keeps the *first* encountered
definition. So with multiple definitions imported there would be a
disagreement between expected definition in `ObjCInterfaceType.Decl` and
actual definition `ObjCInterfaceDecl::getDefinition` which can lead to
incorrect diagnostic.

Fix by not tracking definition in `ObjCInterfaceType` explicitly but by
getting it from redeclaration chain.

Partially reverted 919fc500 keeping the
modified test case as the correct behavior is achieved in a different
way.

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

Variant where the load is larger than the store. Make sure we
don't forward this.

Reviewed By: dblaikie

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

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

Based on post-commit review discussion on
2bd84938 with Richard Smith.

Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).

This was originally committed in 277623f4

Reverted in f9ad1d1c due to breakages
outside of clang - lldb seems to have some strange/strong dependence on
"char [N]" versus "char[N]" when printing strings (not due to that name
appearing in DWARF, but probably due to using clang to stringify type
names) that'll need to be addressed, plus a few other odds and ends in
other subprojects (clang-tools-extra, compiler-rt, etc).

As discussed in D112016, our current requirement of speculatability
for ephemeral is overly strict: What we really care about is that
the instruction will be DCEd once the assume is dropped. For that
it is sufficient that the instruction is side-effect free and not
a terminator.

In particular, this allows non-dereferenceable loads to be ephemeral
values.

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

Use hash code instead of unsigned for the hash return value.

This reverts commit 69708477 to unblock
instrprof-darwin-exports.c failure on MacOS bots.

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

This reverts commit baea663a.

Causes crashes, e.g. https://lab.llvm.org/buildbot/#/builders/77/builds/10715.

This reverts commit 0eed292f, there
are compiler-rt build failures that appear to have been introduced
by this change.

This effectively mirrors the logging in dialect conversion, which has proven
very useful for understanding the pattern application process.

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

Move a few methods out of line and clean up comments.

Otherwise this can result a poison value on some platforms see https://bugs.llvm.org/show_bug.cgi?id=51204

Reviewed By: ezhulenev

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

When cross-compiling, these tests will fail. For now leave the host arch
check that was already there since I don't know why it was added.

This patch is extracted from D111337. It introduce the
CharacterExprHelper that helps dealing with character in FIR.

Reviewed By: schweitz, awarzynski

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



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>

shuf (bo X, Y), (bo X, W) --> bo (shuf X), (shuf Y, W)

This is motivated by an example in D111800
(although that patch avoids the problem for that particular example).

The pattern is shown in reduced form with:
https://llvm.org/PR52178
https://alive2.llvm.org/ce/z/d8zB4D

There is no difference on the PhaseOrdering test from D111800
because the aarch64 cost model says that the shuffle cost is 3 while
the fadd cost is 2.

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

This clears the memory used for the Clang AST before we run LLVM passes.

https://llvm-compile-time-tracker.com/compare.php?from=d0a5f61c4f6fccec87fd5207e3fcd9502dd59854&to=b7437fee79e04464dd968e1a29185495f3590481&stat=max-rss
shows significant memory savings with no slowdown (in fact -O0 slightly speeds up).

For more background, see
https://lists.llvm.org/pipermail/cfe-dev/2021-September/068930.html.

Turn this off for the interpreter since it does codegen multiple times.

Relanding with fix for -print-stats: D111973

Relanding with fix for plugins: D112190

If you'd like to use this even with plugins, consider using the features
introduced in D112096.

This can be turned off with -Xclang -no-clear-ast-before-backend.

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

This test case, reduced from an internal test failure, shows how we may
incorrectly skip the insertion of VSETVLI instructions when doing
cross-basic-block analysis.

The entry block ends in a `e32,mf2`. Its single successor, %bb.1, ends with a
`e8,mf8`, but for a mask-type instruction, so is considered compatible.
This means that the info %bb.1 is merged into its predecessor so
produces a `e32,mf2`. When it comes to the last block, which requires a
`e32,mf2`, we skip the insertion of a vsetvli because all predecessors
were determined to preserve the right vtype.

However, when %bb.1 is actually laid out it does actually need a
`e8,mf8` vsetvli, since the previous instruction has a different tail
policy. This means that when execution flows from %bb.1 to %bb.3, the
`vadd.vx` is misconfigured.

Reviewed By: craig.topper

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

This change restructures the cache used in IPT to point not to the first special instruction, but to the first instruction which *could* be special. That is, the cached reference is always equal to the first special, or comes before it in the block.

This avoids expensive block scans when we are removing special instructions from the beginning of the block. At the moment, this case is not heavily used, though it does trigger in GVN when doing CSE of calls. The main motivation was a change I'm no longer planning to move forward with, but the cache optimization seemed worthwhile as a minor perf win at low cost.

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