Use SetVector instead of DenseSet to ensure we always generate the same
name for the same function. This issue is found in
https://github.com/llvm/llvm-project/issues/53768.

Reviewed By: quinnp, rdzhabarov

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

Summary;
This path adds printing support for the linker wrapper. When the user
passes `-v` it will not print the commands used by the linker wrapper to
indicate to the user what is happening during the linking.

The return value is not a boolean instead of a tri-state.
Suggested by Peter Smith in D120640.

According to Linux documentation (see e.g. https://linux.die.net/man/3/closedir):

> A successful call to `closedir()` also closes the underlying file
> descriptor associated with `dirp`.

Thus, calling `close()` after a successful call to `closedir()` is at
best redundant. Worse, should a different thread open a file in-between
the calls to `closedir()` and `close()` and get the same file descriptor,
the call to `close()` might actually close a different file than was
intended.

rdar://89251874

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

Fold ExtractSliceOp when the source is a constant.

Add R_RISCV_SUB6 relocation

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

Default type legalization will create sext_inreg+abs, but we may
not be able to remove the sext_inreg.

Instead this patch expands abs during type legalization to
Y = sraiw X, 31; subw(xor X, Y), Y) which doesn't require the input
to be sign extended.

This gives a big improvement for some neg-abs tests where the
abs is used more than the the neg. Previously the abs was expanded
a different way before and after type legalization. Now they are
expanded in a similar way enabling more CSE.

Reviewed By: asb

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

This has been unused ever since it was committed in b8a501cc.

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

(X u< 2) ? -X : -1 --> sext (X != 0)
(X u> 1) ? -1 : -X --> sext (X != 0)

https://alive2.llvm.org/ce/z/U3y5Bb
https://alive2.llvm.org/ce/z/hgi-4p

This is part of solving:

See #54053

There has been some internal confusion lately as to how cpu_dispatch and
cpu_specific dispatch to processors, so this patch clarifies the
documentation to make it more clear that:

1- Unlike ICC, we do not consider the vendor string (that is, an AMD
processor might result in something other than generic)

2- there are some processors that aren't really distinguishable thanks
to the library limitation, so the variant being selected is unspecified.

In reality, I believe the 'stable_sort' makes it so the 1st one that
meets the requirements is the one that is selected (and that matches my
experimented result), but I don't want to limit our implementation.

Currently bottom-to-top reordering analysis counts orders of the
operands and then adds natural order counts for the operand users. It is
very conservative, this the user nodes themselves may require
reordering. Patch improves bottom-to-top analysis by checking for the
user nodes if they require/allows the reordring. If the user node must
be reordered, has reused scalars, is an alternate op vectorization node,
is a non-ordered gather node or may allow reordering because of the
reordered operands, such node is considered as the node that allows
reodring and is not counted as a node with the natural order.

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

This change can be seen as code cleanup but motivation is more performance related.
While browsing perf reports captured during Linux build we can notice unusual portion of instructions executed in std::vector<std::string> copy constructor like:

0.59%     0.58%  clang-14    clang-14      [.] std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
                                                                std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::vector

or even:

1.42%     0.26%  clang    clang-14             [.] clang::LangOptions::LangOptions
       |
        --1.16%--clang::LangOptions::LangOptions
                  |
                   --0.74%--std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
                            std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::vector

After more digging we can see that relevant LangOptions std::vector members (*Files, ModuleFeatures and NoBuiltinFuncs)
are constructed when Lexer::LangOpts field is initialized on list:

Lexer::Lexer(..., const LangOptions &langOpts, ...)
            : ..., LangOpts(langOpts),

Since LangOptions copy constructor is called by Lexer(..., const LangOptions &LangOpts,...) and local Lexer objects are created thousands times
(in Lexer::getRawToken, Preprocessor::EnterSourceFile and more) during single module processing in frontend it makes std::vector copy constructors surprisingly hot.

Unfortunately even though in current Lexer implementation mentioned std::vector members are unused and most of time empty,
no compiler is smart enough to optimize their std::vector copy constructors out (take a look at test assembly): https://godbolt.org/z/hdoxPfMYY even with LTO enabled.
However there is simple way to fix this. Since Lexer doesn't access *Files, ModuleFeatures, NoBuiltinFuncs and any other LangOptions fields (but only LangOptionsBase)
we can simply get rid of redundant copy constructor assembly by changing LangOpts type to more appropriate const LangOptions reference: https://godbolt.org/z/fP7de9176

Additionally we need to store LineComment outside LangOpts because it's written in SkipLineComment function.
Also FormatTokenLexer need to be adjusted a bit to avoid lifetime issues related to passing local LangOpts reference to Lexer.

After this change I can see more than 1% speedup in some of my microbenchmarks when using Clang release binary built with LTO.
For Linux build gains are not so significant but still nice at the level of -0.4%/-0.5% instructions drop.

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

This set is only used with contains operations, so there is no
need to use a SetVector.

This adds the following two folds:

Fold 1:
   setcc_merge_zero(
       all_active, extend(nxvNi1 ...), != splat(0))
  -> nxvNi1 ...

Fold 2:
   setcc_merge_zero(
       pred, extend(nxvNi1 ...), != splat(0))
  -> nxvNi1 and(pred, ...)

Reviewed By: david-arm

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

This reverts the revert commit ff93260b.

The underlying issue causing the PPC bot failures has been fixed in
cbaac147 and a corresponding test case has been added in
ad2cad1c.

Original message:

    This patch adds a new VPScalarIVStepsRecipe to handle building scalar
    steps.

    In the first patch, it only handles the case where there is no vector
    induction variable needed.

    Reviewed By: Ayal

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

Otherwise, the driver will insert e.g. -lgcc_s when
CLANG_DEFAULT_UNWINDLIB=libgcc is set during the clang build.

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

Lower the power operation for real, integer
and complex.

The power operation is lowered to library calls.

This patch is part of the upstreaming effort from fir-dev branch.

Depends on D120403

Reviewed By: schweitz

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

This patch rearranges emission of CFI instructions, so the resulting
DWARF and `.eh_frame` information is precise at every instruction.

The current state is that the unwind info is emitted only after the
function prologue. This is fine for synchronous (e.g. C++) exceptions,
but the information is generally incorrect when the program counter is
at an instruction in the prologue or the epilogue, for example:

```
stp	x29, x30, [sp, #-16]!           // 16-byte Folded Spill
mov	x29, sp
.cfi_def_cfa w29, 16
...
```

after the `stp` is executed the (initial) rule for the CFA still says
the CFA is in the `sp`, even though it's already offset by 16 bytes

A correct unwind info could look like:
```
stp	x29, x30, [sp, #-16]!           // 16-byte Folded Spill
.cfi_def_cfa_offset 16
mov	x29, sp
.cfi_def_cfa w29, 16
...
```

Having this information precise up to an instruction is useful for
sampling profilers that would like to get a stack backtrace. The end
goal (towards this patch is just a step) is to have fully working
`-fasynchronous-unwind-tables`.

Reviewed By: danielkiss, MaskRay

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

This patch addresses @paulwalker-arm's comment on D117900 to
only update/write the by-ref operands iff the function returns
true. It also handles a few more cases where a series of added
offsets can be folded into the base pointer, rather than just looking
at a single offset.

Reviewed By: paulwalker-arm

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

These are failing on our silent bot:
https://lab.llvm.org/staging/#/builders/162/builds/358

$ <run cmd>
main
foo
bar
baz
SanitizerCoverage: ./sanitizer_coverage_trace_pc_guard-dso.cpp.tmp.2122517.sancov: 2 PCs written
SanitizerCoverage: ./sanitizer_coverage_trace_pc_guard-dso.cpp.tmp_2.so.2122517.sancov: 1 PCs written
SanitizerCoverage: ./sanitizer_coverage_trace_pc_guard-dso.cpp.tmp_1.so.2122517.sancov: 1 PCs written
$ <sancov cmd>
ERROR: Coverage points in binary and .sancov file do not match.

Also reproduces if you build for Thumb on v8 hardware.

Doesn't fail when built with Arm only code so I guess the Thumb mode bit
in the PCs might be the issue.

Improve the LinalgOp verification to ensure the iterator types is known. Previously, unknown iterator types have been ignored without warning, which can lead to confusing bugs.

Reviewed By: nicolasvasilache

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

Exit values of vector inductions are generated completely independent of
the induction recipes. Consider them for removal, if they are not used
in loop.

This fixes a crash exposed by 49b23f45.

The Cortex-A55 scheduling model is used for -mcpu=generic, meaning it
can have a wider effect than just the A55. The changes to the A55
scheduling model seems to have caused performance regressions on
Cortex-A510 device which have latencies closer to the original and
different forwarding paths.

This partially reverts the changes from D117003, at least until we can
do something to improve Cortex-A510. According to my results, this
improves the A510 results without altering the A55 very much.

[clang-format] Treat && followed by noexcept operator as a binary operator inside template arguments

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

Reviewed By: curdeius, MyDeveloperDay

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

Add test with a induction phi that is not used in the vector loop, but
by an lcssa phi in the loop exit.

Add more functions as taint sources to GenericTaintChecker.

Reviewed By: steakhal

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

This should no longer be necessary now that we canonicalize to
intrinsics. Might not be strictly NFC due to worklist order.

Summary: This is an initial implementation of lvm-objcopy for XCOFF32.
Currently only supports simple copying, op-passthrough to follow.

Reviewed By: jhenderson, shchenz

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

This isn't necessary anymore, now that we canonicalize SPF min/max
to intrinsics. Might not be strictly NFC due to worklist order
changes.

Also add a run line to check interleaving only. This test covers the PPC
buildbot failures caused by 49b23f45.

Only call it for intrinsic min/max. The moved implementation is
unchanged apart from the one-use check: It is now hardcoded to
one-use, without the two-use special case for SPF.

As SPF min/max is canonicalized to intrinsics before this point,
this change should be entirely NFC.

This happens after SPF -> intrinsic canonicalization, and as such
should be entirely NFC.

SPF integer min/max is canonicalized to min/max intrinsics before
this code is reached, so this should be entirely NFC.