Unlike most other freeze tests in the file, this is showing a missing SimplifyDemandedBits simplification instead of a merge of the ops

The rotation amount is always modulo, so won't introduce poison/undef

This reverts commit c1bf4c3c.

This patch adds more tests for AIX. It follows https://reviews.llvm.org/D134820 which added a minimal set of tests for the newly added AIX options. These new tests were originally created by https://reviews.llvm.org/D119109. Since we do not plan to land https://reviews.llvm.org/D119109 in its current shape to add the AIX specific options, we incorporate the relevant tests developed.

Reviewed By: w2yehia

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

Fixes #58545

Without a freeze, this transform can leak poison to the output:
https://alive2.llvm.org/ce/z/GJuF9i

This makes the transform as uniform as possible, and it can help
reduce patterns like issue #58313 (although that particular
example probably still needs another transform).

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

I love C++17!

chromium_framework_less_dwarf on my 16-core Mac Pro shows no stat sig change in wall time but a slight decrease in user time:

```
           base           diff           difference (95% CI)
sys_time   1.759 ± 0.037  1.761 ± 0.033  [  -0.9% ..   +1.1%]
user_time  4.920 ± 0.043  4.886 ± 0.051  [  -1.2% ..   -0.2%]
wall_time  5.950 ± 0.117  5.900 ± 0.116  [  -1.8% ..   +0.2%]
samples    26             37
```

Reviewed By: #lld-macho, thakis

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

Tests taken from https://reviews.llvm.org/D56214 and ported to
InstCombine for https://reviews.llvm.org/D136015.

When a CU attaches some ranges for a subprogram or an inlined code, the CU should be that of the subprogram/inlined code that was emitted.
If not, then these emitted ranges will use the incorrect base of the CU in `emitRangeList`.

A reproducible example is:
When linking these two LLVM IRs,  dsymutil will report no mapping for range or inconsistent range data warnings.

`foo.swift`
```swift
import AppKit.NSLayoutConstraint

public class Foo {

    public var c: Int {
        get {
            Int(NSLayoutConstraint().constant)
        }
        set {
        }
    }

}
```

`main.swift`
```swift
// no mapping for range
let f: Foo! = nil
// inconsistent range data
//let l: Foo = Foo()
```

Reviewed By: dblaikie

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

Spliiter => Splitter

This allows patterns with real 'and' instructions because
those are safe to transform:
https://alive2.llvm.org/ce/z/7-U_Ak

This reverts commit d4650d09.

Reverted because it causes several X86 CodeGen test failures in a build
with LLVM_ENABLE_EXPENSIVE_CHECKS=ON.

Make sure we test the code path where we parse
function templates instantiated with C-arrays.

The test case, kinds04_q10.f90, should run only for X86. Now it is
unexpected passed since 8686ff1d.
Add "-triple x86_64-unknown-linux-gnu" so that the test is for
testing the target X86 linux.

To help better test the effects of D136478

The type parameter we used to pass to call() was unused. Use the same
implementation for void and value-returning function calls.

Remove the double Call() implementation to reduce code duplication. Then
fix Function::getSource() so we can diagnose instance pointers being
null.

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

... using value_or instead of the if-else statement.

Function parameters need to be checked before the function is called.

This broke a builder:
https://lab.llvm.org/buildbot/#builders/139/builds/29923

Assert that the previous call left the stack empty, as well as that
successful interpretations leave an empty stack.

Without this, clients are unable to rename often-used symbols in larger
projects.

Reviewed By: kadircet

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

Repeated call to Instruction::hasMetadata() and lookup in
getContext().pImpl->ValueMetadata are not needed when we always work on
the same instruction, avoid them.

This simple change leads to interesting and consistent speedups in
compile time, around -0.5% according to http://llvm-compile-time-tracker.com, see

        http://llvm-compile-time-tracker.com/compare.php?from=9708d88017d0c9adaea65a4f5a5b589b67f292e2&to=88482b9addd5917e9c5226847efeb5451c5f78c0&stat=instructions

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

Now includes the name of the graph and duplicate section.

Reviewed By: michaelrj

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

Reviewed By: michaelrj

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

Reviewed By: michaelrj

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

Reviewed By: cota

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

... instead of mapping them to the intermediate object file.
This matches ld64.

Reviewed By: #lld-macho, Roger

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

Include symbol sizes (present after {D135883}) as well as an example of
a dead-stripped symbol.

One of the first few instructions being probed has an opcode that's more
likely to change with work on X86 target, so just regexp-ing it.