Currently we use a combined metric TargetTransformInfo::TCK_SizeAndLatency
when estimating the specialization bonus. This is suboptimal, and in some
cases erroneous. For example we shouldn't be weighting the codesize decrease
attributed to constant propagation by the block frequency of the dead code.
Instead only the latency savings should be weighted by block frequency. The
total codesize savings from all the specialization arguments should be
deducted from the specialization cost.

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

Add the defines for the `cl_ext_image_raw10_raw12` extension.

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

Use the maximum 64 for BitWidth of getVScaleRange to avoid returning an empty range.

the previous changes bring in a Buildbot failure because MinSVEVectorSize = MinSVEVectorSize.
    error: explicitly assigning value of variable of type 'unsigned int' to itself [-Werror,-Wself-assign]

Reviewed By: sdesmalen, nikic, dmgreen
Differential Revision: https://reviews.llvm.org/D155708

Reviewed By: arsenm

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

Since it was deprecated since clang-tidy 16.

Fixes #62020

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

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

If the return type of a function is void, ReturnType is not set, but we
used to emit a RVOPtr instruction, which doesn't make sense for a
function returning void.

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

This changes the TLS regset to not only be dynamic in that it could
exist or not (though it always does) but also of a dynamic size.

If SME is present then the regset is 16 bytes and contains both tpidr
and tpidr2.

Testing is the same as tpidr. Write from assembly, read from lldb and
vice versa since we have no way to predict what its value should be
by just running a program.

Reviewed By: omjavaid

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

DeclPrinter::PrintConstructorInitializers did not consider delegating initializers. As result, the output contained an "NULL TYPE" for delegating constructors.

Reviewed By: aaron.ballman

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

Pull out repeated hasOneUse checks. Simplify some conditions. Reduce
indentation.

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

This patch expands testing coverage for ReplaceWithVeclib pass
when SLEEF vector library is used. It adds testing for all LLVM
intrinsics which correspond to math functions from libm.

llrint, llround and lrint are not included as currently
IR verifier pass does not allow to use vector types with them.

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

When dealing with copy constructor, the compiler can emit an
UncheckedDerivedToBase implicit cast for the CXXConstructorExpr of the
base class. In such case, when trying to copy the src storage location
to its destination, we will fail on the assert checking that location
types are the same.

When copying from derived to base class, it is acceptable to break that
assumption to only copy common fields from the base class.

Note: the provided test crashes the process without the changes made to
copyRecord.

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

This fixes the handling of "transparent" ListInitExpr, when they're only
used as a copy constructor for records.

Without the fix, the two tests are crashing the process.

This reverts commit 67005c8e.

The Scalable Matrix Extension (SME) adds a new Scalable Vector mode
called "streaming SVE mode".

In this mode a lot of things change, but my understanding overall
is that this mode assumes you are not going to move data out of
the vector unit very often or read flags.

Based on "E1.3" of "Arm® Architecture Reference Manual Supplement,
The Scalable Matrix Extension (SME), for Armv9-A".

https://developer.arm.com/documentation/ddi0616/latest/

The important details for debug are that this adds another set
of SVE registers. This set is only active when we are in streaming
mode and is read from a new ptrace regset NT_ARM_SSVE.
We are able to read the header of either mode at all times but
only one will be active and contain register data.

For this reason, I have reused the existing SVE state. Streaming
mode is just another mode value attached to that state.

The streaming mode registers do not have different names in the
architecture, so I do not plan to allow users to read or write the
inactive mode's registers. "z0" will always mean "z0" of the active
mode.

Ptrace does allow reading inactive modes, but the data is of little
use. Writing to inactive modes will switch to that mode which would
not be what a debugger user would expect. So lldb will do neither.

Existing SVE tests have been updated to check streaming mode and
mode switches. However, we are limited in what we can check given
that state for the other mode is invalidated on mode switch.

The only way to know what mode you are in for testing purposes would
be to execute a streaming only, or non-streaming only instruction in
the opposite mode. However, the CPU feature smefa64 actually allows
all non-streaming mode instructions in streaming mode.

This is enabled by default in QEMU emulation and rather than mess
about trying to disable it I'm just going to use the pseduo streaming
control register added in a later patch to make these tests more
robust.

A new test has been added to check SIMD read/write from all the modes
as there is a subtlety there that needs noting, though lldb
doesn't have to make extra effort to do so.

If you are in streaming mode and write to v0, when you later exit
streaming mode that value may not be in the non-streaming state.
This can depend on how the core works but is a valid behaviour.

For example, say I am stopped here:
mov x0, v0.d[0]

And I want to update v0 in lldb. "register write v0 ..." should update
the v0 that this instruction is about to see. Not the potential other
copy of v0 in the non-streaming state (which is what I attempted in
earlier versions of this patch).

Not to mention, switching out of streaming mode here would be unexpected
and difficult to signal to the user.

Reviewed By: omjavaid

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

There is some pointer simplification code originally from isKnownNonNull
that is now better suited to be in isKnownNonZeroFromOperator.

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

We add some subclasses of Sched to reduce code which cast string
to `SchedWrite`/`SchedRead`.

Besides, we add `ReadVMask` iff pseudo is masked. And this is the
reason why this patch isn't a NFC since we add it for all pseudos
before.

`ReadMergeOp` will be added in D155654.

Reviewed By: michaelmaitland

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

So it actually works when using dump().

This reverts commit 28f53227.

Related to D152486.  The following functions are included in this revision: `acosf`, `acoshf`, `asinf`, `asinhf`, `atanf`, `atanhf`, `ceil`, `ceilf`, `copysign`, `copysignf`, `cos`, `cosf`, `cosh`, `coshf`, `exp10f`, `exp2f`, `expf`, `expm1f`, `fabs`, `fabsf`, `fdim`, `fdimf`, `floor`, `floorf`, `fma`, `fmaf`, `fmax`, `fmaxf`, `fmin`, `fminf`, `fmod`, `fmodf`, `frexp`, `frexpf`, `hypot`, `hypotf`, `ilogb`, `ilogbf`, `ldexp`, `ldexpf`, `llrint`, `llrintf`, `llround`, `llroundf`, `pow`, and `powf`.

Reviewed By: jhuber6

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

Add a new InvalidCast op for this purpose and emit a diagnostic.

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

Use the maximum 64 for BitWidth of getVScaleRange to
avoid returning an empty range.

Reviewed By: sdesmalen, nikic, dmgreen
Differential Revision: https://reviews.llvm.org/D155708

We might be trying to return a pointer or reference to a local variable,
which doesn't work.

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

1. Zvbc is not part of Zvkn.
2. Zvbc is not part of Zvks.
3. Add extensions implied into shorthand extension.

Also arrange its definition order as more closely its order in document.

Please refer to https://reviews.llvm.org/D152117 and https://reviews.llvm.org/D153836.

Document: https://github.com/riscv/riscv-crypto/releases/download/v20230620/riscv-crypto-spec-vector.pdf

Reviewed By: craig.topper

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

Reviewed By: pengfei, skan

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

Mach-O can just use the global variable `FirstPrivateHeader`.
If we ever manage to remove global variables, we can add a Config
variable to Dumper. Either case, the parameter is not needed.

Reviewed By: jhenderson

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

Reviewed By: bryanpkc

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

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

Reviewed By: arsenm

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

See
https://discourse.llvm.org/t/clang-cl-exe-support-for-c-modules/72257
for details. Simply, the user of clang-cl.exe can't get a good
experience with C++20 modules now. While we don't have resources to
support it well now, we should make it clear in the documentation.

The case was wrong before, and somehow I only looked at the condition
before.

We will use this opcode for conditionally executed statements that are
invalid in a constant expression.

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