It should be oclc_abi_version* instead of abi_version*.

Reviewed by: Artem Belevich

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

Last year I was working at Swift to add support for [Localization of Compiler Diagnostic Messages](https://forums.swift.org/t/localization-of-compiler-diagnostic-messages/36412/41). We are currently using YAML as the new diagnostic format. The LLVM::YAMLParser didn't have a support for multiline string literal folding and it's crucial to have that for the diagnostic message to help us keep up with the 80 columns rule. Therefore, I decided to add a multiline string literal folding support to the YAML parser.

Patch By: @HassanElDesouky (Hassan ElDesouky)

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

Since https://reviews.llvm.org/D120334, passing a temporary LangOptions
object to Lexer results in stack-use-after-scope.

Reviewed By: rnk

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

I think the immediate values we check for on the GREV nodes already
protect this, but better to be explicit.

Just adds some lowering test for complex operations. These were not
added when the lowering landed.

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

Reviewed By: schweitz

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

Motivation:

```
int foo(int x, int y) { // any compiler will happily inline this function
    return x / y;
}

int test(int x, int y) {
    int r = 0;
    [[clang::noinline]] r += foo(x, y); // for some reason we don't want any inlining here
    return r;
}

```

In 2018, @kuhar proposed "Introduce per-callsite inline intrinsics"  in https://reviews.llvm.org/D51200 to solve this motivation case (and many others).

This patch solves this problem with call site attribute. The implementation is "smaller" wrt approach which uses new intrinsics and thanks to https://reviews.llvm.org/D79121 (Add nomerge statement attribute to clang), we have got some basic infrastructure to deal with attrs on statements with call expressions.

GCC devs are more inclined to call attribute solution as well, as builtins are problematic for them - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104187. But they have no patch proposal yet so..  We have free hands here.

If this approach makes sense, next future steps would be support for call site attributes for always_inline / flatten.

Reviewed By: aaron.ballman, kuhar

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

The function doesn't modify anything, and took minimal effort to get
const-correct, AND is necessary for a patch I've been working on for
concepts.

`uniform_int_distribution<T>` is UB unless `T` is one of the non-character,
non-boolean integer types (`short` or larger). However, libc++ has never
enforced this. D114129 accidentally made `uniform_int_distribution<bool>`
into an error. Make it now *intentionally* an error; and likewise for the
character types and all user-defined class and enum types; but permit
`__[u]int128_t` to continue working.

Apply the same static_assert to all the integer distributions.

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

This follows the general direction of D118736 that
`_LIBCPP_HAS_NO_INCOMPLETE_RANGES` does *not* guard anything outside
of the `std::ranges::` namespace itself. This means we must permit
`ranges::less` etc. in no-ranges mode; that seems fine to me.

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

Since https://reviews.llvm.org/D120334 we shouldn't pass temporary LangOptions to Lexer.
This change fixes stack-use-after-scope UB in LocalizationChecker found by sanitizer-x86_64-linux-fast buildbot
and resolve similar issue in HeaderIncludes.

TODO: merge flat with global promoting to flat.

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

To decrease difference for D120650. Also, rename some `OutputSection *sec` (and
`cmd`) to the more common `osec`.

This patch adds llvm-ifs commandline guide

Differential Review: https://reviews.llvm.org/D118514

This reverts commit 31049941.

extractvalue (any_mul_with_overflow X, -1), 0 --> -X

There are similar other potential transforms that we could do as
noted by the last TODO in the test diffs.

Fixes #54053

The test used to run whole O3 pipeline. Modify it to contain LLVM IR right
before LV and limit passes to "-loop-vectorizer -simplifycfg".

For the RUN line with forced VF force interleave factor as well to simplify
CHECKs as interleaving isn't related to the purpose of the test.

I also tried to add "noalias" to pointer arguments in
@test_gather_not_profitable_pr48429 but LAI seems unable to use them.

Reviewed By: fhahn

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

I think the function does the correct thing internally, but it's
confusing to read.

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