Also delete trailing whitespace in lib/orc/CMakeLists.txt

1) We now use the count size in FDO as the main factor to deal with pre-inliner.
Currently we use the number of sample records in the SampleFDO profile. But
that only counts the top-level body sample records (not including the nested
call-sites). We are seeing some big functions not being updated because of
this. I think using the count size in FDO profile is more reasonable to judge if
the function is likely to be inlined to the callers in pre-inliner.

(2) We use getMaxCount in SampleFDO rather the HeadSample to determine if
if the function is hot in SampleFDO. This is in-sync with the logic
in the compiler (also HeadSample can be 0).

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

Purely so that these can be easily autogened without spurious diffs

SimplifyDemandedBits can 0 the upper bits and targetShrinkDemandedConstant
isn't alway able to recover it.

At least part of that may be because targetShrinkDemandedConstant
only runs in the last DAGCombine. Might be worth seeing what happens
if we move it post type legalization.

Immediate was messed up by SimplfyDemandedBits.

This patch changes order of searching for reductions vs other vectorization possibilities.
The idea is if we do not match a reduction it won't be harmful for further attempts to
find vectorizable operations on a vector build sequences. But doing it in the opposite
order we have good chance to ruin opportunity to match a reduction later.
We also don't want to try vectorizing binary operations too early as 2-way vectorization
may effectively prohibit wider ones leading to producing less effective code.

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

Added folders for tosa.greater fold splat values.

Reviewed By: NatashaKnk

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

Math dialect operations currently do not limit transformations
applied to them, which means that they potentially behave like
clang's -ffast-math mathematics. Clang marks math functions with
readnone attribute enabling more optimizations.

This change does the same for functions used by MathToLibm convertor.
In particular, this enables LLVM LICM for tan() call in
Polyhedron/mp_prop_design_11 compiled with flang.

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

Previously time tracing features were hidden behind an optional CMake
option. This was because `libomptarget` was not based on the LLVM
libraries at that time. Now that `libomptarget` is an LLVM library we
should be able to freely use the `LLVMSupport` library whenever we want
and do not need to guard it in this way.

Reviewed By: jdoerfert

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

Mostly just to make a future patch easier to review.

It is not reliable. See #57430.

This builds on D132771 to invert (setlt 0, X) to (setlt X, 1) and
vice versa.

Reviewed By: reames

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

We can rewrite to (bnez (or/and (setne), Z) is Z is 0/1.

Alternatively, we could canonicalize to (xor (or/and (setne), Z), 1)
even if there is no branch. The xor would not always get removed,
but it might enable other DeMorgan combines. I decided to be
conservative for this first patch and require the xor to be removed.

I have a couple other invertible setccs I will add in a follow up
patch.

Reviewed By: reames

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

Reviewed By: probinson

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

To have finer control of IR uwtable attribute generation. For target code generation,
IR nounwind and uwtable may have some interaction. However, for frontend, there are
no semantic interactions so the this new `nouwtable` is marked "SimpleHandler = 1".

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

This reverts commit 2d665717 due to
test failure:

http://45.33.8.238/win/65224/step_7.txt

The patch addresses the linkage of the new autogenerated pass constructors, which, being declared as friend functions, resulted in having an inline nature and thus their implementations not being exported.

Reviewd By: mehdi_amini, rriddle

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

This fixes https://github.com/llvm/llvm-project/issues/57336. It was exposed by a recent SCEV change, but appears to have been a long standing issue.

Note that the whole insert into the loop instead of a split exit edge is slightly contrived to begin with; it's there solely because IndVarSimplify preserves the CFG.

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

This reverts commit 992e10a3.

Breaks builds with LLVM_INCLUDE_TESTS=OFF, see comments in D132438.

A loop can recursively increase/decrease a function local static
variable and make itself finite.  For example,

```
void f() {
  static int i = 0;
  i++;
  while (i < 10)
     f();
}

```

Such cases are not considered by `InfiniteLoopCheck`.  This commit
fixes this problem by detecting usages of static local variables
and recursions.

Reviewed by: NoQ, njames93
Differential Revision: https://reviews.llvm.org/D128401

Stores for constant floats must be vectorized, improve analysis in SLP
vectorizer for stores.

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

Add test cases for AArch64 that show over-eager SLP vectorization on
AArch64, where keeping the things scalar allows efficient lowering using
scalar fmas.

The tables constructed by semantics that describe derived types to
the runtime support library must not include "vtable" entries for
the deferred type-bound procedures of abstract derived types;
these can turn out to be unsatisfiable external references to
procedures whose interfaces were used in the definitions of those
bindings.

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

Improve utility of `FileCheck` output when a shell test fails.

The conflict is from:

1. On failure, `FileCheck` prints 5 lines of context
2. Shell tests first source `lit-lldb-init`, having the effect of printing its contents

If a `FileCheck` failure happens at the beginning of the input, then the
context shown is the `lit-lldb-init`, as it's over 5 lines and is the first
thing printed. As the init contents are fairly static, and presumably
uninteresting to most test failures, it seems reasonable to not print it.

Unfortunately it's not possible to use the `--source-quietly` flag in the lldb
invocation, because it will quiet all other `--source` flags on the command
line, making many tests fail.

This fix is a level of indirection, where a new sibling file named
`lit-lldb-init-quiet` is created, and its static contents are:

```
command source -C --silent-run true lit-lldb-init
```

This achieves the result of loading `lit-lldb-init` quietly. The `-C` flag
loads the path relatively.

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

While investigation slow tests, I looked into why `TestMultithreaded.py`. One
of the reasons is that it determines the architecture of lldb by running:

```
lldb -o 'file path/to/lldb' -o 'quit'
```

On my fairly fast machine, this takes 24 seconds, and `TestMultithreaded.py`
calls this function 4 times.

With this change, this command now takes less than 0.2s on the same machine.

The reason it's slow is symbol table and debug info loading, as indicated by
the new progress events printed to the console. One setting reduced the time in
half:

```
settings set target.preload-symbols false
```

Further investigation, by profiling with Instruments on macOS, showed that
loading time was also caused by looking for scripts. The setting that
eliminates this time is:

```
settings set target.load-script-from-symbol-file false
```

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

Do not fold the endline which contains tokens after the end of range.

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

Add a canonicalizetion step for
reinterpret_cast(extract_strided_metadata).
This step replaces this sequence of operations by either:
- A noop, i.e., the original memref is directly used, or
- A plain cast of the original memref

The choice is ultimately made based on whether the original memref type
is equal to what the reinterpret_cast iss producing. For instance, the
reinterpret_cast could be changing some dimensions from static to
dynamic and in such case, we need to keep a cast.

The transformation is currently only performed when the reinterpret_cast
uses exactly the same arguments as what the extract_strided_metadata
produces. It may be possible to be more aggressive here but I wanted to
start with a relatively simple MLIR patch for my first one!

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

Currently, QueryDriverDatabase returns an empty compile command
if it could not determine the file type.

This failure mode is unnecessarily destructive; it's better to
just return the incoming compiler command, which is still more
likely to be useful than an empty command.

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

This new pass provides an alternative to the current conversion pass
that converts sparse tensor types and sparse primitives to opaque pointers
and calls into a runtime support library. This pass will map sparse tensor
types to actual data structures and primitives to actual code. In the long
run, this new pass will remove our dependence on the support library, avoid
the need to link in fully templated and expanded code, and provide much better
opportunities for optimization on the generated code.

Reviewed By: Peiming

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

Mostly just modeled after vp.fneg except there is a
"functional instruction" for fneg while fabs is always an
intrinsic.

Reviewed By: fakepaper56

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

This patch fixes issues with generating assembly format parsers for
operations that use the `operands` directive or which have unnamed
arguments or results.

This patch also fixes a function in `OpAsmParser` that always produced
an error when trying to resolve variadic operands with the same type.

Fixes #51841

Reviewed By: rriddle

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

Reviewed By: arcbbb, kito-cheng

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

This should avoid some copies of the output iterator.

Reviewed By: #libc, Mordante

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

The existing code was incorrect if we had more than one conditional
branch instruction in a basic block. Though I don't think that will
occur, using analyzeBranch detects that as an unsupported case.

Overall this results in simpler code in RISCVRedundantCopyElimination.

Reviewed By: reames, kito-cheng

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

[mlir][dataflow] Consolidate AbstractSparseLattice::markPessimisticFixpoint() and AbstractDenseLattice::reset() into Abstract{Sparse,Dense}DataFlowAnalysis::setToEntryState().

### Rationale

For a program point where we cannot reason about incoming dataflow (e.g. an argument of an entry block), the framework needs to initialize the state.

Currently, `AbstractSparseDataFlowAnalysis` initializes such state to the "pessimistic fixpoint", and `AbstractDenseDataFlowAnalysis` calls the state's `reset()` function.

However, entry states aren't necessarily the pessimistic fixpoint. Example: in reaching definition, the pessimistic fixpoint is `{all definitions}`, but the entry state is `{}`.

This awkwardness might be why the dense analysis API currently uses `reset()` instead of `markPessimisticFixpoint()`.

This patch consolidates entry point initialization into a single function `setToEntryState()`.

### API Location

Note that `setToEntryState()` is defined in the analysis rather than the lattice, so that we allow different analyses to use the same lattice but different entry states.

### Removal of the concept of optimistic/known value

The concept of optimistic/known value is too specific to SCCP.

Furthermore, the known value is not really used: In the current SCCP implementation, the known value (pessimistic fixpoint) is always `Attribute{}` (non-constant). This means there's no point storing a `knownValue` in each state.

If we do need to re-introduce optimistic/known value, we should put it in the SCCP analysis, not the sparse analysis API.

### Terminology

Please let me know if "entry state" is a good terminology.

I chose "entry" from Wikipedia (https://en.wikipedia.org/wiki/Data-flow_analysis#Basic_principles).

Another term I can think of is "boundary" (https://suif.stanford.edu/~courses/cs243/lectures/L3-DFA2-revised.pdf) which might be better since it also makes sense for backward analysis.

Reviewed By: Mogball

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

Add extra test coverage and updates some slightly stale comments as
pointed out in D132365.

Create a field in VOPProfile called DstRCVOP3DPP to allow the VOP3
versions of DPP instructions to have a different destination register
class than the non-VOP3 encoding. NFC for current instructions, but
planned to be functional in upcoming ones.

Reviewed By: rampitec

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