Instead of having this script be part of the OSS-Fuzz repository, I think
it makes more sense to have it alongside the rest of the fuzzing targets
in libc++.

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

If you use -stop-after or similar options, llc will normally print MIR.
This patch checks for -filetype=null as a special case to disable MIR
printing. As the comment says, "The Null output is intended for use for
performance analysis ...", and I found this useful for timing a subset
of the passes that llc runs without the significant overhead of printing
MIR just to send it to /dev/null.

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

This trait simply adds a fold of f(f(x)) = f(x) when an operation is labelled as idempotent

Reviewed By: rriddle, andyly

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

This reverts commit eb9f7c28.

Previously this was incorrectly handling linking of the contained
type, so this merges the fixes from D88973.

This is more correctly handled by canEvaluateTruncated (one use checks etc.) and covers all the tests cases that were added for this fold.

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

This matches an existing marking in enum.path.format.pass.cpp.

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

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

[libcxx] [test] Use string() instead of native() as parameter to std::ifstream/ofstream in copy_file_large.pass.cpp

This fixes building with libstdc++ for windows. MS STL has got
ifstream/ofstream overloads that taken wide strings though.

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

`SourceManager::createFileID` asserts that the given `FileEntry` is not
null, so remove the logic that passed in `nullptr`. Since we just added
the file to an in-memory FS via an API that cannot fail, use
`llvm_unreachable` on the error path. Didn't use an `assert` since it
seems cleaner semantically to check the error (and better,
hypothetically, for updating the API to use `Expected` instead of
`ErrorOr`).

I noticed this incidentally while auditing calls to `createFileID`.

Calling "ASSOCATED(NULL()) was causing an internal check of the compiler to
fail.

I fixed this by changing the entry for "ASSOCIATED" in the intrinsics table to
accept "AnyPointer" which contains a new "KindCode" of "pointerType".  I also
changed the function "FromActual()" to return a typeless intrinsic when called
on a pointer, which duplicates its behavior for BOZ literals.  This required
changing the analysis of procedure arguments.  While testing processing for
procedure arguments, I found another bad call to `CHECK()` which I fixed.

I made several other changes:
  -- I implemented constant folding for ASSOCIATED().
  -- I fixed handling of NULL() in relational operations.
  -- I implemented semantic analysis for ASSOCIATED().
    -- I noticed that the semantics for ASSOCIATED() are similar to those for
       pointer assignment.  So I extracted the code that pointer assignment uses
       for procedure pointer compatibility to a place where it could be used by
       the semantic analysis for ASSOCIATED().
    -- I couldn't figure out how to make the general semantic analysis for
       procedure arguments work with ASSOCIATED()'s second argument, which can
       be either a pointer or a target.  So I stopped using normal semantic
       analysis for arguments for ASSOCIATED().
  -- I added tests for all of this.

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

These don't really have function bodies to try to eliminate. This also
has a good chance of just producing invalid IR since intrinsics can
have special operand constraints (e.g. metadata arguments aren't valid
for an arbitrary call). This was wasting quite a bit of time producing
and failing on invalid IR when replacing dbg.values with undefs.

This would end up killing part of the result super-register, resulting
in a verifier error on a later use of the overlapping registers.  We
could add kills of any non-aliasing registers, but we should be moving
away from relying on kill flags.

When opening a minidump, we might discover that it reports a UUID for a
module that doesn't match the build ID, but rather a hash of the .text
section (according to either of two different hash functions, used by
breakpad and Facebook respectively).  The current logic searches for a
module by filename only to check the hash; this change updates it to
first search by directory+filename.  This is important when the
directory specified in the minidump must be interpreted relative to a
user-provided sysoort, as the leaf directory won't be in the search path
in that case.

Also add a regression test; without this change, module validation fails
because we have just the placeholder module which reports as its path
the platform path in the minidump.

Reviewed By: clayborg

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

Enables support for transforming loops of the form
```
for (auto I = Cont.rbegin(), E = Cont.rend(); I != E;++I)
```

This is done automatically in C++20 mode using `std::ranges::reverse_view` but there are options to specify a different function to reverse iterator over a container.
This is the first step, down the line I'd like to possibly extend this support for array based loops
```
for (unsigned I = Arr.size() - 1;I >=0;--I) Arr[I]...
```

Currently if you pass a reversing function with no header in the options it will just assume that the function exists, however as we have the ASTContext it may be as wise to check before applying, or at least lower the confidence level if we can't find it.

Reviewed By: alexfh

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

This is the libcxxabi counterpart of D89545, and would have been part
of that patch if I'd spotted it soon enough (oops). One test in
libcxxabi is using the `%lu` printf format to refer to `size_t`, which
should be `%zu`.

Reviewed By: ldionne, #libc_abi

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

rGcc69d211 introduced several uses of `printf` with format
directives `%lu` and `%ld` to format values of type `size_t` and
`ptrdiff_t` respectively.

That doesn't reliably work in all C implementations, because those
types aren't necessarily the same thing as 'long int': sometimes
they're not even the same size, and when they are the same size, they
might be officially defined as int rather than long (for example),
which causes clang to emit a diagnostic for the mismatch.

C has special-purpose printf modifier letters for these two types, so
it's safer to use them. Changed all `%lu` on `size_t` to `%zu`, and
all `%ld` on `ptrdiff_t` to `%td`.

Reviewed By: ldionne, #libc

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

This reverts commit c2bd20ef652 and the follow up fix 16605bba6fb.

The tools/llvm-cov/warnings.h continues to fail on Windows platforms even
after the follow up, for example on the llvm-clang-win-x-armv7l builder:

    http://lab.llvm.org:8011/#/builders/60/builds/94

- so that global variables in numbered address spaces could be properly
  analyzed.

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

They seem to have been placed under stream.iterators by mistake.
This is relevant for some upcoming UNSUPPORTED markup.

Logic of widenWithVariantUse is split into check and transform
part, unlike any other transform in IndVars. We want to pass some
extra flags from analysis to transform part and standartize
the code at once, so merging them together.

Match the canonicalization code that was added to matchFunnelShift at rG02295e6d

Based on the rotation equivalents in rotate.ll

Variable ExtendOperExpr only exists to check whether it is a SCEV ext.
We create it as SCEV ext right here, so semantically this check is
trivially true. In theory, it may fail if SCEV is smart enough and can
simplify the expression. However, no matter whether it is an ext or not,
we never use this fact for further reasoning. So this code is currently
useless and in theory may become harmful with SCEV's development.

We do not expect any behavior changes with removing it. If it caused
negative changes, the patch should be reverted.

Some facts have already been checked in widenWithVariantUse and then
checked again in widenWithVariantUseCodegen. The latter is redundant,
we can replace it with asserts.

It was reverted because of negative compile time impact. In this version,
less powerful proof methods are used (non-recursive reasoning only), and
scope limited to constant End values to avoid explision of complex proofs.

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

TypeSize comparisons using overloaded operators should be replaced by
the new isKnownXY comparators when the operands can be fixed-length or
scalable vectors.

In ValueTracking there are several uses of the overloaded operators in
`isKnownNonZero` and `ComputeMultiple`. In the former we already bail
out on scalable vectors since we currently have no way to represent
DemandedElts, and the latter is operating on scalar integers, so we can
assume fixed-size in both instances.

Reviewed By: david-arm

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

Prep work for PR35155 - renamed narrowRotate to narrowFunnelShift, rewrote some comments and adjusted code to collect separate shift values, although we bail if they don't match (still only rotations are only actually folded).

I'm trying to match matchFunnelShift as much as possible in case we finally get to merge these one day.