Tests were updated with (without manual fixup):
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34

This patch is a subpart of D125768 intented to make the review easier.

The `SizedOp` struct represents operations to be performed on a certain number of bytes.
It is responsible for breaking them down into platform types and forwarded to the `Backend`.

The `Backend` struct represents a lower level abstraction that works only on types (`uint8_t`, `__m128i`, ...).
It is similar to instruction selection.

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

Update performed using:
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34

memcpy-discriminator.ll was fixed up to use named instructions
and drop the no longer needed bitcasts.

Update performed using (without manual fixup):
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34

Update performed using:
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34

This time without any manual fixup.

The symbol table starts with all the C_FILE symbols.

Reviewed By: shchenz

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

This fixes the combining of constant vector GEP operands in the
optimization of MVE gather/scatter addresses, when opaque pointers are
enabled. As opaque pointers reduce the number of bitcasts between geps,
more can be folded than before. This can cause problems if the index
types are now different between the two geps.

This fixes that by making sure each constant is scaled appropriately,
which has the effect of transforming the geps to have a scale of 1,
changing [r0, q0, uxtw #1] gathers to [r0, q0] with a larger q0. This
helps use a simpler instruction that doesn't need the extra uxtw.

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

Regenerate the test with current O2 result and only run CGP.

This patch adds support for:

* Querying the PSTATE.SM state with @llvm.aarch64.sme.get.pstatesm
* Reading/writing the TPIDR2 register with new
@llvm.aarch64.sme.get.tpidr2 and @llvm.aarch64.sme.set.tpidr2
intrinsics.

Tests added here:

  CodeGen/AArch64/sme-get-pstatesm.ll
  CodeGen/AArch64/sme-read-write-tpidr2.ll

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

For an lvalue reference to a move only view x, views::all(x) gives hard error because the expression inside noexcept is not well formed and it is not SFINAE friendly.

Given a move only view type `V`, and a concept

```
template <class R>
concept can_all = requires {
    std::views::all(std::declval<R>());
};
```

The expression `can_all<V&>` returns
libstdc++: false
msvc stl : false
libc++   : error: static_cast from 'V' to 'typename decay<decltype((std::forward<V &>(__t)))>::type' (aka 'V') uses deleted function
      noexcept(noexcept(_LIBCPP_AUTO_CAST(std::forward<_Tp>(__t))))

The standard spec has its own problem, the spec says it is expression equivalent to `decay-copy(E)` but the spec of `decay-copy` does not have any constraint, which means the expression `decay-copy(declval<V&>())` is well-formed and the concept `can_all<V&>` should return true and should error when instantiating the function body of decay-copy. This is clearly wrong behaviour in the spec and we will probably create an LWG issue. But the libc++'s behaviour is clearly not correct. The `noexcept` is an "extension" in libc++ which is not in the spec, but the expression inside `noexpect` triggers hard error, which is not right.

Reviewed By: #libc, ldionne, var-const

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

As branch on undef is immediate undefined behavior, there is no need
to mark one of the edges as feasible. We can leave all the edges
non-feasible. In IPSCCP, we can replace the branch with an unreachable
terminator.

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

This will allow implementing state-dependent behavior in the future.

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

Previously `#pragma STDC FENV_ACCESS ON` always set dynamic rounding
mode and strict exception handling. It is not correct in the presence
of other pragmas that also modify rounding mode and exception handling.
For example, the effect of previous pragma FENV_ROUND could be
cancelled, which is not conformant with the C standard. Also
`#pragma STDC FENV_ACCESS OFF` turned off only FEnvAccess flag, leaving
rounding mode and exception handling unchanged, which is incorrect in
general case.

Concrete rounding and exception mode depend on a combination of several
factors like various pragmas and command-line options. During the review
of this patch an idea was proposed that the semantic actions associated
with such pragmas should only set appropriate flags. Actual rounding
mode and exception handling should be calculated taking into account the
state of all relevant options. In such implementation the pragma
FENV_ACCESS should not override properties set by other pragmas but
should set them if such setting is absent.

To implement this approach the following main changes are made:

- Field `FPRoundingMode` is removed from `LangOptions`. Actually there
  are no options that set it to arbitrary rounding mode, the choice was
  only `dynamic` or `tonearest`. Instead, a new boolean flag
  `RoundingMath` is added, with the same meaning as the corresponding
  command-line option.

- Type `FPExceptionModeKind` now has possible value `FPE_Default`. It
  does not represent any particular exception mode but indicates that
  such mode was not set and default value should be used. It allows to
  distinguish the case:

    {
        #pragma STDC FENV_ACCESS ON
	...
    }

  where the pragma must set FPE_Strict, from the case:

    {
        #pragma clang fp exceptions(ignore)
        #pragma STDC FENV_ACCESS ON
        ...
    }

  where exception mode should remain `FPE_Ignore`.

  - Class `FPOptions` has now methods `getRoundingMode` and
  `getExceptionMode`, which calculates the respective properties from
  other specified FP properties.

  - Class `LangOptions` has now methods `getDefaultRoundingMode` and
  `getDefaultExceptionMode`, which calculates default modes from the
  specified options and should be used instead of `getRoundingMode` and
  `getFPExceptionMode` of the same class.

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

Fixes #37402

Reviewed By: ldionne

Spies: EricWF, avogelsgesang, libcxx-commits, arphaman

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

`std::function` has been deprecated for a few releases now. Remove it with an option to opt-back-in with a note that this option will be removed in LLVM 16.

Reviewed By: ldionne, #libc

Spies: #libc_vendors, EricWF, jloser, libcxx-commits

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

This patch clean up some code for upstreaming and add couple of
missing tests that were left in fir-dev.

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

Reviewed By: jeanPerier, PeteSteinfeld

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



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

This allows adding facts without necessarily having a corresponding
CmpInst.

Originally, the nested build was set up with the CMake command
`execute_process` which implicitly passes CC/CXX variables for
the configured compiler, which then was picked up by the nested
CMake. (This CMake behaviour, to implicitly pass such variables
is up for discussion and might change in the future; see
https://gitlab.kitware.com/cmake/cmake/-/issues/21378.)

How the nested cmake build is set up was changed in
aa7d6db5 / D40229 - the old behaviour
was brought along by manually passing
-DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER} to the nested cmake
configuration. This was then later made optional in
f5f0fffe / D40947. But still,
the default if the user doesn't pass
CROSS_TOOLCHAIN_FLAGS_${target_name} (e.g. CROSS_TOOLCHAIN_FLAGS_NATIVE)
is to pass in the surrounding build's compiler - which usually
doesn't work, and is quite non-obvious to figure out.
...

The code has been reformatted in accordance with the code style. Some
function comments were extended to the Doxygen ones and reworded a bit
to eliminate the duplication of the function's/class' name in the
comment.

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

Reviewed By: lntue

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

This changes the implementation of the formatter. Instead of inheriting
from a specialized parser all formatters will use the same generic
parser. This reduces the binary size.

The new parser contains some additional fields only used in the chrono
formatting. Since this doesn't change the size of the parser the fields
are in the generic parser. The parser is designed to fit in 128-bit,
making it cheap to pass by value.

The new format function is a const member function. This isn't required
by the Standard yet, but it will be after LWG-3636 is accepted.
Additionally P2286 adds a formattable concept which requires the member
function to be const qualified in C++23. This paper is likely to be
accepted in the 2022 July plenary.

Depends on D121530

NOTE parts of the code now contains duplicates for the current and new parser.
The intention is to remove the duplication in followup patches. A general
overview of the final code is available in D124620. That review however lacks a
bit of polish.

Most of the new code is based on the same algorithms used in the current code.

The final version of this code reduces the binary size by 17 KB for this example
code
```

int main() {
  {
    std::string_view sv{"hello world"};
    std::format("{}{}|{}{}{}{}{}{}|{}{}{}{}{}{}|{}{}{}|{}{}|{}", true, '*',
                (signed char)(42), (short)(42), (int)(42), (long)(42), (long long)(42), (__int128_t)(42),
                (unsigned char)(42), (unsigned short)(42), (unsigned int)(42), (unsigned long)(42),
                (unsigned long long)(42), (__uint128_t)(42),
                (float)(42), (double)(42), (long double)(42),
                "hello world", sv,
                nullptr);
  }
  {
    std::wstring_view sv{L"hello world"};
    std::format(L"{}{}|{}{}{}{}{}{}|{}{}{}{}{}{}|{}{}{}|{}{}|{}", true, L'*',
                (signed char)(42), (short)(42), (int)(42), (long)(42), (long long)(42), (__int128_t)(42),
                (unsigned char)(42), (unsigned short)(42), (unsigned int)(42), (unsigned long)(42),
                (unsigned long long)(42), (__uint128_t)(42),
                (float)(42), (double)(42), (long double)(42),
                L"hello world", sv,
                nullptr);
  }
}

```

Reviewed By: #libc, ldionne

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

Reviewed By: andreil99

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

There are some cases that we use si_if/si_else in unatural way.
Just skip them.

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

Reviewed by: critson

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

NewGVN will find operator from other context. ValueTracking currently doesn't have a way to run completely without context instruction.
So it will use operator itself as conext instruction.
If the operator in another branch will never be executed but it has an assume, it may caused value tracking use the assume to do wrong simpilfy.

It would be better to make these simplification queries not use context at all, but that would require some API changes.
For now we just use the orignial instruction as context instruction to fix the issue.

Fix #56039

Reviewed By: nikic

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

createInductionResumeValues creates a phi node placeholder
without filling incoming values. Then it generates the incoming values.

It includes triggering of SCEV expander which may invoke SSAUpdater.
SSAUpdater has an optimization to detect number of predecessors
basing on incoming values if there is phi node.
In case phi node is not filled with incoming values - the number of predecessors
is detected as 0 and this leads to segmentation fault.

In other words SSAUpdater expects that phi is in good shape while
LoopVectorizer breaks this requirement.

The fix is just prepare all incoming values first and then build a phi node.

Reviewed By: fhahn
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D128033

Thanks for Med Ismail Bennani for reporting the debugserver failures.

Summary:
This patch removes a duplicated exit from the OpenMP data envrionment.
We already have an RAII method that guards this environment so it is
unnecessary.

This avoid creating empty bins in AAPointerInfo which can lead to
segfaults. Also ensure we do not try to translate from callee to caller
except if we really take the argument state and move it to the call site
argument state.

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

When determining liveness via Attributor::isAssumedDead(...) we might
end up without a liveness AA or with one pointing into another function.
Neither is helpful and we will avoid both from now on.

Reapplied after fixing the ASAN error which caused the revert:
https://github.com/llvm/llvm-project/commit/db68a25ca90e0da46c9c33b027fa83260073bd28

[lld-macho] Work around odr-use of const non-inline static data member to fix -O0 build after D128298

```
ld.lld: error: undefined symbol: lld::macho::CodeSignatureSection::blockSize
>>> referenced by SyntheticSections.cpp:1253 (/home/maskray/llvm/lld/MachO/SyntheticSections.cpp:1253)
>>>               tools/lld/MachO/CMakeFiles/lldMachO.dir/SyntheticSections.cpp.o:(lld::macho::CodeSignatureSection::writeHashes(unsigned char*) const::$_7::operator()(unsigned long) const)
```

Add a setting to configure how LLDB parses dynamic Objective-C class
metadata. By default LLDB will choose the most appropriate method for
the target OS.

Differential revision: https://reviews.llvm.org/D128312

Recent revisions of the Objective-C runtime changed
objc_debug_class_getNameRaw() in a way that no longer triggers lazy
names to be instantiated. This has the unintended side-effect of making
generic bridged Swift classes, such as _SwiftDeferredNSDictionary<U,V>
to become invisible to the Objective-C runtime.

This patch detects this situation and forces the names to be
instantiated by calling class_getName() and discarding the result before
calling objc_debug_class_getNameRaw() again.

Many thanks to Mike Ash for outlining the solution and Adrian for
authoring the downstream patch.

rdar://95245318

Differential revision: https://reviews.llvm.org/D128306

This reverts commit 6d6268dc.

Review: https://reviews.llvm.org/D125712

erf and round op are able to lowered to libm supporting vector type as other math operations.

Reviewed By: ftynse

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

According to ministat, this is a small but measurable speedup
(using the repro in PR56121):

    N           Min           Max        Median           Avg        Stddev
x  10     3.7439518     3.7783802     3.7730219     3.7655502   0.012375226
+  10     3.6149218      3.692198     3.6519327     3.6502951   0.025905601
Difference at 95.0% confidence
	-0.115255 +/- 0.0190746
	-3.06078% +/- 0.506554%
	(Student's t, pooled s = 0.0203008)

(Without 858e8b17, this change here to use parallelFor is an 18% speedup,
and doing 858e8b17 on top of this change is just a 2.55% +/- 0.58% win.
Doing both results in a total speedup of 20.85% +/- 0.44%.)

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

This reverts commit 6f88acf4.

During the reordering transformation we should try to avoid reordering bundles
like fadd,fsub because this may block them being matched into a single vector
instruction in x86.
We do this by checking if a TreeEntry is such a pattern and adding it to the
list of TreeEntries with orders that need to be considered.

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

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

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