This was blocking isTypeLegal call so that we could do a particular
transform on illegal types before type legalization. But the we
create a target specific node using that type. We shouldn't do
that if the type isn't legal. So I think we should just always
make sure the type is legal.

I suspect that in order to get the condition VT to not be a vector
of i1 we already completed type legalization anyway so this probably
doesn't matter much in practice.

It is not enough to replace all uses of users of the function with undef,
the users, we only drop instruction users, so they may stick around.

Let's try different approach - first drop bodies for all the functions
we will drop, which should take care of blockaddress issue the previous
rewrite was dealing with; then, after dropping *all* such bodies,
replace remaining uses with undef (thus all the uses are either
outside of functions, or are in kept functions)
and then finally drop functions.

This seems to work, and passes the *existing* test coverage,
but it is possible that a new issue will be discovered later :)

A new (previously crashing) test added.

We currently fail to match this.

This is just a thin wrapper around computeRegisterLivness which
we can just call directly. The only real difference is that
isSafeToClobberEFLAGS returns a bool and computeRegisterLivness
returns an enum. So we need to check for the specific enum value
that isSafeToClobberEFLAGS was hiding.

I've also adjusted which sites pass an explicit value for
Neighborhood since the default for computeRegisterLivness is 10.

D83904 seems to have changed timeout value on expect_gdbremote_sequence which
was 120 previously. This seems to be causing intermittent failures on
lldb-aarch64-ubuntu buildbot.

This patch fixes the timeout value to see the impact on test suite.

Example:
http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/7401/steps/test/logs/stdio

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

Recommit "[X86] Increase the number of instructions searched for isSafeToClobberEFLAGS in a couple places"

I messed up the bug numbers in the commit message before

Previously this function searched 4 instructions forwards or
backwards to determine if it was ok to clobber eflags.

This is called in 3 places: rematerialization, turning 2 operand
leas into adds or splitting 3 ops leas into an lea and add on some
CPU targets.

This patch increases the search limit to 10 instructions for
rematerialization and 2 operand lea to add. I've left the old
treshold for 3 ops lea spliting as that increases code size.

Fixes PR47024 and PR46315.

Revert "[X86] Increase the number of instructions searched for isSafeToClobberEFLAGS in a couple places"

This reverts commit 44b260cb.

I messed up the bug number in the commit message so I'm reverting
to fix it.

Use scaleShuffleMask helper for the shuffle(hadd,hadd) canonicalization.

Previously this function searched 4 instructions forwards or
backwards to determine if it was ok to clobber eflags.

This is called in 3 places: rematerialization, turning 2 operand
leas into adds or splitting 3 ops leas into an lea and add on some
CPU targets.

This patch increases the search limit to 10 instructions for
rematerialization and 2 operand lea to add. I've left the old
treshold for 3 ops lea spliting as that increases code size.

Fixes PR47024 and PR43014

This was introduced at rGe2022367, and the CreateVectorSplat(unsigned NumElements) variant calls it internally

Motivation (from PR37674):

const char *ss[] = {
  "foo", "bar",
  "baz", "qux"  // <-- Missing comma!
  "abc", "xyz"
  };

This kind of bug was recently also found in LLVM codebase (see PR47030).

Solves PR47038, PR37674

Reviewed By: aaron.ballman

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

SimplifyCFG has two main folds for resumes - one when resume is directly
using the landingpad, and the other one where resume is using a PHI node.

While for the first case, we were already correctly ignoring all the
PHI nodes, and both the debug info intrinsics and lifetime intrinsics,
in the PHI-based-one, we weren't ignoring PHI's in the resume block,
and weren't ignoring lifetime intrinsics. That is clearly a bug.

On RawSpeed library, this results in +9.34% (+81) more invoke->call folds,
-0.19% (-39) landing pads, -0.24% (-81) invoke instructions
but +51 call instructions and -132 basic blocks.

Though, the run-time performance impact appears to be within the noise.

Fixes PR47017 (a regression when fixing PR46169): if __wrap_ is shared,
it is not exported.

Follow-up to D82716 / rGea71ba11
We do not have the fabs removal fold in IR yet for the case
where the sqrt operand is repeated, so that's another potential
improvement.

Two DebugInfo tests currently `FAIL` on Sparc:

  LLVM :: DebugInfo/Generic/2010-06-29-InlinedFnLocalVar.ll
  LLVM :: DebugInfo/Generic/array.ll

both in a similar way.  E.g.

  : 'RUN: at line 1';   /var/llvm/local-sparcv9-A/bin/llc -O2 /vol/llvm/src/llvm-project/local/llvm/test/DebugInfo/Generic/2010-06-29-InlinedFnLocalVar.ll -o - | /var/llvm/local-sparcv9-A/bin/FileCheck /vol/llvm/src/llvm-project/local/llvm/test/DebugInfo/Generic/2010-06-29-InlinedFnLocalVar.ll

  /vol/llvm/src/llvm-project/local/llvm/test/DebugInfo/Generic/2010-06-29-InlinedFnLocalVar.ll:4:10: error: CHECK: expected string not found in input
  ; CHECK: debug_info,
           ^

On `amd64-pc-solaris2.11`, the corresponding line is

  .section        .debug_info,"",@progbits

while on `sparcv9-sun-solaris2.11` we have only

  .section        .debug_info

This happens because Sparc currently emits `.section` directives using the
style of the Solaris/SPARC assembler (controlled by `SunStyleELFSectionSwitchSyntax`).

This patch takes the easy way out and allows both forms while tightening the
check to only match the `.section` directive.

Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`,
`x86_64-pc-linux-gnu`, and `x86_64-apple-darwin20.0.0`.

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

Will be reenabled after investigating and fixing the problem.

This eliminates UnitTest's dependency on FPUtil and hence prevents
non-math tests from depending indirectly on FPUtil. The patch
essentially moves some of the existing pieces into a library of its own.

Along the way, renamed add_math_unittest to add_fp_unittest.

Reviewed By: lntue

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

This patch also fixes a minor issue that shape.rank should allow
returning !shape.size. The dialect doc has such an example for
shape.rank.

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

This patch adds an optimization that folds select(freeze(icmp eq/ne x, y), x, y)
to x or y.
This was needed to resolve slowdown after D84940 is applied.

I tried to bake this logic into foldSelectInstWithICmp, but it wasn't clear.
This patch conservatively writes the pattern in a separate function,
foldSelectWithFrozenICmp.

The output does not need freeze; https://alive2.llvm.org/ce/z/X49hNE (from @nikic)

Reviewed By: nikic

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

The new code added is still very x86_64 specific. AArch64 support will
be added very soon and refactoring of the loader code will be done as
part of the patches adding it.

Reviewed By: asteinhauser

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

Previously the transform was doing these two canonicalizations
(x > y) ? x : y -> (x >= y) ? x : y
(x < y) ? x : y -> (x <= y) ? x : y

But those don't seem to be useful generally. And they actively
pessimize the cases in PR47049.

This patch limits it to
(x > 0) ? x : 0 -> (x >= 0) ? x : 0
(x < -1) ? x : -1 -> (x <= -1) ? x : -1

These are the cases mentioned in the comments as the motivation
for the canonicalization. These allow the CMOV to use the S
flag from the compare thus improving opportunities to use a TEST
or the flags from an arithmetic instruction.

Fix include/mlir/Reducer/ReductionNode.h:79:18: warning: private field 'parent' is not used [-Wunused-private-field]

This reverts commit 9f24640b.

We hit some dead-locks on thread exit in some configurations: TLS exit handler is taking a lock.
Temporarily reverting this change as we're debugging what is going on.

glibc/sysdeps/unix/sysv/linux/x86_64/sigaction.c libc.a(sigaction.o) has a CIE
with the augmentation string "zRS". Support 'S' to allow --icf={safe,all}.

This revision aims to provide a new API, `checkTilingLegality`, to
verify that the loop tiling result still satisifes the dependence
constraints of the original loop nest.

Previously, there was no check for the validity of tiling. For instance:

```
func @diagonal_dependence() {
  %A = alloc() : memref<64x64xf32>

  affine.for %i = 0 to 64 {
    affine.for %j = 0 to 64 {
      %0 = affine.load %A[%j, %i] : memref<64x64xf32>
      %1 = affine.load %A[%i, %j - 1] : memref<64x64xf32>
      %2 = addf %0, %1 : f32
      affine.store %2, %A[%i, %j] : memref<64x64xf32>
    }
  }

  return
}
```

You can find more information about this example from the Section 3.11
of [1].

In general, there are three types of dependences here: two flow
dependences, one in direction `(i, j) = (0, 1)` (notation that depicts a
vector in the 2D iteration space), one in `(i, j) = (1, -1)`; and one
anti dependence in the direction `(-1, 1)`.

Since two of them are along the diagonal in opposite directions, the
default tiling method in `affine`, which tiles the iteration space into
rectangles, will violate the legality condition proposed by Irigoin and
Triolet [2]. [2] implies two tiles cannot depend on each other, while in
the `affine` tiling case, two rectangles along the same diagonal are
indeed dependent, which simply violates the rule.

This diff attempts to put together a validator that checks whether the
rule from [2] is violated or not when applying the default tiling method
in `affine`.

The canonical way to perform such validation is by examining the effect
from adding the constraint from Irigoin and Triolet to the existing
dependence constraints.

Since we already have the prior knowlegde that `affine` tiles in a
hyper-rectangular way, and the resulting tiles will be scheduled in the
same order as their respective loop indices, we can simplify the
solution to just checking whether all dependence components are
non-negative along the tiling dimensions.

We put this algorithm into a new API called `checkTilingLegality` under
`LoopTiling.cpp`. This function iterates every `load`/`store` pair, and
if there is any dependence between them, we get the dependence component
  and check whether it has any negative component. This function returns
  `failure` if the legality condition is violated.

[1]. Bondhugula, Uday. Effective Automatic parallelization and locality optimization using the Polyhedral model. https://dl.acm.org/doi/book/10.5555/1559029
[2]. Irigoin, F. and Triolet, R. Supernode Partitioning. https://dl.acm.org/doi/10.1145/73560.73588

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