Added folders for tosa.sub that handles bypassing divide by one,
and a zero numerator.

Reviewed By: NatashaKnk

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

Current implementation promotes a non-cold function in the SampleFDO profile
into a hot function in the FDO profile. This is too aggressive. This patch
promotes a hot functions in the SampleFDO profile into a hot function, and a
warm function in SampleFDO into a warm function in FDO.

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

Added folders for tosa.sub that handles bypassing sub-zero,
fold subtraction of two splat tensors.

Reviewed By: NatashaKnk

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

Added folders for tosa.sub that handles bypassing sub-zero,
fold subtraction of two splat tensors.

Reviewed By: NatashaKnk

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

This patch has the following changes:
(1) Handling of internal linkage functions (static functions)
Static functions in FDO have a prefix of source file name, while they do not
have one in SampleFDO. Current implementation does not handle this and we are
not updating the profile for static functions. This patch fixes this.

(2) Handling of -funique-internal-linakge-symbols
Again this is for the internal linkage functions. Option
-funique-internal-linakge-symbols can now be applied to both FDO and SampleFDO
compilation. When it is used, it demangles internal linkage function names and
adds a hash value as the postfix.

When both SampleFDO and FDO profiles use this option, or both
not use this option, changes in (1) should handle this.

Here we also handle when the SampleFDO profile using this option while FDO
profile not using this option, or vice versa.

There is one case where this patch won't work: If one of the profiles used
mangled name and the other does not. For example, if the SampleFDO profile
uses clang c-compiler and without -funique-internal-linakge-symbols, while
the FDO profile uses -funique-internal-linakge-symbols. The SampleFDO profile
contains unmangled names while the FDO profile contains mangled names. If
both profiles use c++ compiler, this won't happen. We think this use case
is rare and does not justify the effort to fix.

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

This overload just wraps a bitvector, and in most cases a bitvector
could be used directly instead of a list.

Reviewed By: rriddle

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

Don't require the AND has one use and don't depend on
targetShrinkDemandedConstant turning C2 into 0xffffffff. Instead,
check that the constant is 0xffffffff after replacing any bits
that will be shifted out with 1s.

Another way to fix this might be to prevent SimplifyDemandedBits
from destroying the ANDI after type legalization using
targetShrinkDemandedBits. That would prevent the CSE that created
this mess. targetShrinkDemandedBits is currently only enable after
legalize ops. Quick experiment shows we can't just change when it
runs, we would need to try a different heuristic for post type
legalization.

This patch adds a an `eraseArguments` function that erases a subrange of
a block's arguments. This can be used inplace of the terrible pattern

```
block->eraseArguments(llvm::to_vector(llvm::seq(...)));
```

Reviewed By: rriddle

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

I keep finding myself needing to rule this out as a possible source of scalarization, so add debug output like we have for other instructions we decide to scalarize.

This reverts commit ce6989fd.

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