This reverts commit 37eb9d13.

Test failures have been fixed:

- ubsan failure fixed by 72eac42f
- warn-unsafe-buffer-usage-fixits-local-var-span.cpp fixed by
  03cc52df (wasn't related)
- test-output-format.ll failure was spurious, build failed at
  https://lab.llvm.org/buildbot/#/builders/54/builds/3545 (b4431b2d)
  but passed at
  https://lab.llvm.org/buildbot/#/builders/54/builds/3546 (5ae99be0)
  which is before my revert
  https://github.com/llvm/llvm-project/compare/b4431b2d945b6fc19b1a55ac6ce969a8e06e1e93...5ae99be0377248c74346096dc475af254a3fc799

Original commit message:

    Depends on https://reviews.llvm.org/D142861.

    Alternative to https://reviews.llvm.org/D137601.

    xxHash is much faster than djbHash. This makes a simple Rust test case with a large cons...

This fixes an infinite loop if isa<T>(II->getOperand(1)) is true.
Update Base at the top of the loop, before the continue.

Reviewed By: ABataev

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

Support for the unratified 1.0-rc3 specification was introduced in
D133443. The specification has since been ratified (in November 2022
according to the recently ratified extensions list
<https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions>.

A review of the diff
<https://github.com/riscv/riscv-zawrs/compare/V1.0-rc3...main> of the
1.0-rc3 spec vs the current/ratified document shows no changes to the
instruction encoding or naming. At one point, a note was added
<https://github.com/riscv/riscv-zawrs/commit/e84f42406a7c88eb92452515b2035144a7023a51>
indicating Zawrs depends on the Zalrsc extension (not officially
specified, but I believe to be just the LR/SC instructions from the A
extension). The final text ended up as "The instructions in the Zawrs
extension are only useful in conjunction with the LR instructions, which
are provided by the A extension, and which we also expect to be provided
by a narrower Zalrsc extension in the future." I think it's consistent
with this phrasing to not require the A extension for Zawrs, which
matches what was implemented.

No intrinsics are implemented for Zawrs currently, meaning we don't need
to additionally review whether those intrinsics can be considered
finalised and ready for exposure to end users.

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

We can swap operands and use fltq.s and fleq.s. Similar for D and H.

This is for consistency with the C++20-style bit manipulation
functions in <bit>.

Per the psABI, the arch string should be normalised to (amongest other
things) always include the full version of each extension in form
zfoo1p0. riscv-attributes-place.s didn't conform to this, which is not a
problem for the current parsing logic, but this behaviour would change
with a patch I'm about to propose.

This makes riscv-sttributes-place.s feature a valid arch string, and
maintains test coverage for this particular form of invalid arch string
by adding it to riscv-attributes.s.

This prevents the instructions being invalid for the subtarget.

At the moment, properlyDominates(A, A) can return true via
LocalComesBefore. Add an early exit to ensure it returns false if
A == B.

Note: no test has been added because the existing test suite covers this
case already with libc++ with assertions enabled.

Fixes https://github.com/llvm/llvm-project/issues/60850.

This is pure code motion, to ensure that the check if we have a valid llvmModule
comes before trying to set option on this module.

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

These tests fail in D144331, for the same reason other format tests fail
in GCC. This is a resource issue.

Re-introduce the patch that was reverted previously.
In the first attempt, the checks would not be able to
read from the global option, since getLocalOrGlobal
only works with string types. Additional logic is needed
in order to support both use cases in the transition
period. All that logic will be removed when the local
options are fully removed.

We have a number of checks designed to analyze problems
in header files only, for example:

bugprone-suspicious-include
google-build-namespaces
llvm-header-guard
misc-definitions-in-header
...

All these checks duplicate the same logic and options
to determine whether a location is placed in the main
source file or in the header. More checks are coming
up with similar requirements.

Thus, to remove duplication, let's move this option
to the top-level configuration of clang-tidy (since
it's something all checks should share).

Add a deprecation notice for all checks that use the
local option, prompting to update to the global option.

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

This reverts commit b6eed9a8.

This should fix https://github.com/rust-lang/rust/issues/107681.

Return undefined to a noundef return value is undefined.

Example:

```
define noundef i32 @test_ret_noundef(i1 %cond) {
entry:
  br i1 %cond, label %bb1, label %bb2
bb1:
  br label %bb2
bb2:
  %r = phi i32 [ undef, %entry ], [ 1, %bb1 ]
  ret i32 %r
}
```

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

TypeSystemClang.cpp:4855:13: error: enumeration value 'WasmExternRef' not handled in switch [-Werror,-Wswitch]

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

These correspond to islessgreater and it inverse.

Currently, MlirTranslateMain only executes one of the requested translations, and does not error if multiple are specified. This commit enables translations to be chained in the specified order.

This makes round-trip tests easier, since existing import/export passes can be reused and no combined round-trip passes have to be registered (example: mlir-translate  -serialize-spirv -deserialize-spirv).

Additionally, by leveraging TranslateRegistration with file-to-file TranslateFunctions, generic pre- and post-processing can be added before/after conversion to/from MLIR.

Reviewed By: lattner, Mogball

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

Instead of special casing Zfa in the custom inserters, select the
correct instructions during isel.

BuildPairF64 we can do with pattern, but SplitF64 requires custom
selection due to the two destinations.

If we didn't need SplitF64 without Zfa, I would have an extract low
and extract high ISD opcode for Zfa to avoid that issue.

Given this transformation: X % Y -> X - (X / Y) * Y

This patch strips off the poison-generating flag of X / Y such as exact, because it may make the optimized form result poison whereas X % Y does not.

The issue was reported here: https://github.com/llvm/llvm-project/issues/60748

Reviewed By: nikic

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

"unsigned long" can be 8 bytes, but the code assumes 4.

This this the real root cause D122215 was reverted.

Reviewed By: fhahn

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

Breaks bots
https://lab.llvm.org/buildbot/#/builders/236/builds/2349
https://lab.llvm.org/buildbot/#/builders/74/builds/17361
https://lab.llvm.org/buildbot/#/builders/168/builds/11972

This reverts commit 7be55b00.

Given concat(zip1(a, b), zip2(a, b)), we can convert that to a 128bit zip1(a, b)
if we widen a and b out first.

Fixes #54226

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

Add cases for the following ops:
    - 0-X            -- https://alive2.llvm.org/ce/z/6C75Li
    - bitreverse(X)  -- https://alive2.llvm.org/ce/z/SGG1q9
    - bswap(X)       -- https://alive2.llvm.org/ce/z/p7pzwh
    - ctpop(X)       -- https://alive2.llvm.org/ce/z/c5y3BC
    - abs(X)         -- https://alive2.llvm.org/ce/z/yxXGz_
                        https://alive2.llvm.org/ce/z/rSRg4K
    - uadd_sat(X, Y) -- https://alive2.llvm.org/ce/z/Zw-y4W
                        https://alive2.llvm.org/ce/z/2NRqRz
                        https://alive2.llvm.org/ce/z/M1OpF8

Reviewed By: nikic

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

Add cases for the following ops:
    - 0-X
    - bitreverse(X)
    - bswap(X)
    - ctpop(X)
    - abs(X)
    - uadd_sat(X, Y)

Reviewed By: nikic

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

[ValueTracking] Add KnownBits patterns `xor(x, x - 1)` and `and(x, -x)` for knowing upper bits to be zero

These two BMI pattern will clear the upper bits of result past the
first set bit. So if we know a single bit in `x` is set, we know that
`results[bitwidth - 1, log2(x) + 1] = 0`.

Alive2:
blsmsk: https://alive2.llvm.org/ce/z/a397BS
blsi: https://alive2.llvm.org/ce/z/tsbQhC

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

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

Reviewed By: nikic

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

* Deployment Versions for targets
* Run Search Paths
* Text vs Data Segment attributes to symbols

Reviewed By: pete

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

"TableGenBackends.h" has declarations of emitters.

The extending loads combine tries to prefer sign-extends folding into loads vs
zexts, and in cases where a G_ZEXTLOAD is first used by a G_ZEXT, and then used
by a G_SEXT, it would select the G_SEXT even though the load is already
zero-extending.

Fixes issue #59630