[analyzer] Fix for incorrect handling of 0 length non-POD array construction

Prior to this patch when the analyzer encountered a non-POD 0 length array,
it still invoked the constructor for 1 element, which lead to false positives.
This patch makes sure that we no longer construct any elements when we see a
0 length array.

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

[lldb][nfc] Remove unused makefile test variables

The variables LLDB_USING_LIBCPP and LLDB_USING_LIBSTDCPP are no longer
used anywhere.

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

[AMDGPU][MC][GFX11][NFC] Add missing tests for SOP instructions

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

[AMDGPU][MC][GFX11][NFC] Update tests for FLAT instructions

Update assembler tests for FLAT instructions; remove redundant gfx11_asm_flat_mnemonic.s.

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

[RISCV][test] Update branch-relaxation.ll with update_llc_test_checks.py [NFC]

Update `llvm/test/CodeGen/RISCV/branch-relaxation.ll` with
`update_llc_test_checks.py`, according to
https://reviews.llvm.org/D130560#3746417:

>>! In D130560#3746417, @luismarques wrote:
>>>! In D130560#3746379, @luismarques wrote:
>> The tests don't seem to have been properly updated with
>> `update_llc_test_checks.py`.
>> `llvm/test/CodeGen/RISCV/branch-relaxation.ll` contains RV64 RUN
>> lines but the corresponding CHECK lines are missing in
>> some functions.
>
> Looking more closely at this, I guess you tried to only include the
> `CHECK-RV64` and `CHECK-RV32` checks when relevant. That's a good
> instinct but I guess it goes a bit against how we normally use
> `update_llc_test_checks.py`. My understanding of the trade-off of
> using that tool is that the test updates are much easier, even if
> sometimes the CHECKs aren't as tight as something more tailormade.

Reviewed By: luismarques

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

Revert "[RISCV][test] Update branch-relaxation.ll with update_llc_test_checks.py [NFC]"

This reverts commit c374789fba484af62a327a9337c7c9107461ee51.

[LLD] [COFF] Fix export directives in object files from -includeoptional

When an object file contains an export directive, we normally do some
amount of deferred processing of them at the end of the linking
process. The -includeoptional option was handled after this, and
any object files (defining new exports) weren't handled.

Move the handling of the -includeoptional into the same late loop
which does the fixups for e.g. export directives.

Ideally, this would also be done for object files that are pulled
in by the wrap options, and for mingw autoimports, but those changes
require more modifications, to make them safe for potentially
being executed multiple times.

This fixes https://github.com/llvm/llvm-project/issues/57243.

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

[flang] [runtime] Fix build warnings if built with mingw

Check whether `F_OK` et al are defined before redefining them; mingw
headers do define them, so check before providing the windows fallback
defines.

Also check `_WIN32` instead of `WIN32`; this is how it's consistently
done in the rest of llvm. (The former is a compiler builtin define,
while the latter isn't, but it's commonly set by e.g. build systems.)

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

[RISCV][test] Update branch-relaxation.ll with update_llc_test_checks.py [NFC]

Update `llvm/test/CodeGen/RISCV/branch-relaxation.ll` with
`update_llc_test_checks.py`, according to
https://reviews.llvm.org/D130560#3746417:

>>! In D130560#3746417, @luismarques wrote:
>>>! In D130560#3746379, @luismarques wrote:
>> The tests don't seem to have been properly updated with
>> `update_llc_test_checks.py`.
>> `llvm/test/CodeGen/RISCV/branch-relaxation.ll` contains RV64 RUN
>> lines but the corresponding CHECK lines are missing in
>> some functions.
>
> Looking more closely at this, I guess you tried to only include the
> `CHECK-RV64` and `CHECK-RV32` checks when relevant. That's a good
> instinct but I guess it goes a bit against how we normally use
> `update_llc_test_checks.py`. My understanding of the trade-off of
> using that tool is that the test updates are much easier, even if
> sometimes the CHECKs aren't as tight as something more tailormade.

[compiler-rt][hwasan] Factor out CanUseTaggingAbi() and EnableTaggingAbi()

Simplify InitializeOsSupport() by separating code for detecting and
enabling the tagged address ABI.

Also drop the unnecessary errno checks (regardless of errno value, we
cannot assume that tagging works if the system call failed) and ensure
prctl(PR_SET_TAGGED_ADDR_CTRL) is only called on Android, not on x86
(where arch_prctl(ARCH_ENABLE_TAGGED_ADDR, kTagBits) is used).

Depends on D132544

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

[BOLT][AArch64] Handle references to the middle of Constant Islands

Fix BinaryContext::handleAddressRef to properly detect references to
other function's Constant islands.

Revieved By: rafauler, yota9

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

[compiler-rt][hwasan] Introduce MaybeDieIfNoTaggingAbi()

Use a helper function to print an error message and die in the case
flags()->fail_without_syscall_abi is set.

Because x86 doesn't have `sysctl abi.tagged_addr_disabled`, do not
mention it in the error message for non-Android runtime.

Depends on D132543

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

[mlir][tensor] Add getMixedSizes helper

This helper function computes the dimensions of a tensor value as OpFoldResults.

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

[NFC][libc] Fix unused variable in string_writer_test test

[NFC][libc] Remove double semicolon

[clang-tidy] Add test to cert-dcl58-cpp (NFC).

Add a test to cert-dcl58-cpp.cpp to verify that crash in github
issue #56902 does not happen.

Reviewed By: njames93

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

[compiler-rt][hwasan] Massage prctl/arch_prctl API constants.

Move the definitions outside InitializeOsSupport(). Also remove the
undefs, as these constants won't be visible outside the .cpp file anyway.

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

[mlir][LLVMIR] Parse some type attributes for LLVM function parameters

With the transition to opaque pointers, type information has been
transferred to function parameter attributes. This patch adds correct
parsing for some of those arguments and fixes some tests, that
previously used UnitAttr for those.

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

[NFC] Fix a misleading comment CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION

[Pipelines] Introduce DAE after ArgumentPromotion

The ArgumentPromotion pass uses Mem2Reg promotion at the end to cutting
down generated `alloca` instructions as well as meaningless `store`s and
this behavior can leave unused (dead) arguments. To eliminate the dead
arguments and therefore let the DeadCodeElimination remove becoming dead
inserted `GEP`s as well as `load`s and `cast`s in the callers, the
DeadArgumentElimination pass should be run after the ArgumentPromotion
one.

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

[lldb][Test] Prevent generating DW_AT_location for unused argument

This test simply checks whether we can print an optimized
function argument. With recent changes to Clang the assumption
that we don't generate a `DW_AT_location` attribute for the
unused funciton parameter breaks.

This patch tries harder to get Clang to drop the location
from DWARF by making it generate an `undef` for `unused1`.
Drop the check for `unused2` since it adds no benefit.

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

SONAME introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION

This reverts commit bc39d7bdd4977a953b2e102f8f7eb479ad78984e.

rename CLANG_SONAME to LIBCLANG_SOVERSION

[clang][cmake] introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION

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

Revert "[Clang] Implement P0848 (Conditionally Trivial Special Member Functions)"

See bug report here: https://github.com/llvm/llvm-project/issues/57351
This reverts commit 7171615099142ed49042c0f27af437b05150dd9b.

[MCContext] Reverse order of DebugPrefixMap sort for generated assembly debug info

Match Clang's sorting, so that longer (more specific) prefix paths will match
before less specific paths.

Reviewed By: MaskRay, raj.khem, #debug-info

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

[DAGCombiner] Use FoldConstantArithmetic instead of dyn_cast in visitFP_ROUND.

Reviewed By: RKSimon

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

[clang][deps] Remove CompilerInvocation from ModuleDeps

The invocation is only ever used to serialize cc1 arguments from, so
instead serialize the arguments inside the dep scanner to simplify the
interface.

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

[clang][tooling] Allow -cc1 arguments in ToolInvocation

ToolInvocation is useful even if you already have a -cc1 invocation,
since it provides a standard way to setup diagnostics, parse arguments,
and handoff to a ToolAction. So teach it to support -cc1 commands by
skipping the driver bits.

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

[InstCombine] recognize bitreverse disguised as shufflevector

This patch complete TODO left in D66965, and achieve
related pattern for bitreverse.

Reviewed By: RKSimon

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

[InstCombine] Add undef elements support for shrinkFPConstantVector

Reviewed By: RKSimon, spatel

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

[gn build] Port 5ce4c9aa0405

[gn build] port 5ce4c9aa0405

Fix CSR update check

D132080 introduced a bug leading to `RegisterClassInfo` caches not
getting invalidated when there was exactly one more CSR register added.

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

[BOLT] Track fragment info for all split fragments

To generate all symbols correctly, it is necessary to record the address
of each fragment. This patch moves the address info for the main and
cold fragments from BinaryFunction to FunctionFragment, where this data
is recorded for all fragments.

Reviewed By: rafauler

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

[BOLT] Allocate FunctionFragment on heap

This changes `FunctionFragment` from being used as a temporary proxy
object to access basic block ranges to a heap-allocated object that can
store fragment-specific information.

Reviewed By: rafauler

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

Revert "MC: make section classification a bit more thorough"

This reverts commit 73a9dfcee24df959b59a46d75dcbdc0bcfb50fe6.

We started to hit assertions when compiling & assembling separately.
See comments in https://reviews.llvm.org/D131270

[mlgo] Fix tests

Missed a few tests in D119507

[SLP][NFC] Refactor SLPVectorizerPass::vectorizeRootInstruction method.

The goal is to separate collecting items for post-processing
and processing them. Post processing also outlined as
dedicated method.

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

[mlir] Remove the element type enum from DenseArrayAttr

The element type enum is not needed to differentiate dense array kinds
because the element type of the shaped type can be used instead.

Reviewed By: mehdi_amini, rriddle

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

[BOLT] Towards FunctionLayout const-correctness

A const-qualified reference to function layout allows accessing
non-const qualified basic blocks on a const-qualified function. This
patch adds or removes const-qualifiers where necessary to indicate where
basic blocks are used in a non-const manner.

Reviewed By: rafauler

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

[AArch64][DAGCombine] Fix a bug in performBuildVectorCombine where it could produce an invalid EXTRACT_SUBVECTOR

EXTRACT_SUBVECTOR requires that Idx be a constant multiple of ResultType's
known minimum vector length.

Something like this will produce an invalid extract_subvector:

t1: v4i16 = .....
t2: i32 = extract_vector_elt t1, Constant:i64<1>
t3: i32 = extract_vector_elt t1, Constant:i64<2>
t4: v2i32 = BUILD_VECTOR t2, t3
// produces
t5: v2i32 = extract_subvector t...., Constant:i64<1>

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

Change-Id: I7a5acf054edee3e89c0f85a28d8869256403ce08

[mlgo] Use TFLite for 'development' mode.

TLite is a lightweight, statically linkable[1], model evaluator, supporting a
subset of what the full tensorflow library does, sufficient for the
types of scenarios we envision having. It is also faster.

We still use saved models as "source of truth" - 'release' mode's AOT
starts from a saved model; and the ML training side operates in terms of
saved models.

Using TFLite solves the following problems compared to using the full TF
C API:

- a compiler-friendly implementation for runtime-loadable (as opposed
  to AOT-embedded) models: it's statically linked; it can be built via
  cmake;
- solves an issue we had when building the compiler with both AOT and
  full TF C API support, whereby, due to a packaging issue on the TF
  side, we needed to have the pip package and the TF C API library at
  the same version. We have no such constraints now.

The main liability is it supporting a subset of what the full TF
framework does. We do not expect that to cause an issue, but should that
be the case, we can always revert back to using the full framework
(after also figuring out a way to address the problems that motivated
the move to TFLite).

Details:

This change switches the development mode to TFLite. Models are still
expected to be placed in a directory - i.e. the parameters to clang
don't change; what changes is the directory content: we still need
an `output_spec.json` file; but instead of the saved_model protobuf and
the `variables` directory, we now just have one file, `model.tflite`.

The change includes a utility showing how to take a saved model and
convert it to TFLite, which it uses for testing.

The full TF implementation can still be built (not side-by-side). We
intend to remove it shortly, after patching downstream dependencies. The
build behavior, however, prioritizes TFLite - i.e. trying to enable both
full TF C API and TFLite will just pick TFLite.

[1] thanks to @petrhosek's changes to TFLite's cmake support and its deps!

[LLDB] Clean up after command fails

`CommandObject::CheckRequirements()` requires m_exe_ctx being cleaned up.

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

[RISCV] Remove cttz/ctlz cost model coverage for the moment

I'd used the wrong signatures for these as I had not remembered we'd added the second boolean argument.  We appear to still parse the old form just fine, but we should use the two argument form in test since that's what the LangRef actually describes.

[compiler-rt][builtins] Add compiler flags to catch potential errors
that can lead to security vulnerabilities

Also, fix a few places that were causing -Wshadow and
-Wformat-nonliteral warnings to be emitted.

This reapplies the patch that was reverted in 0d66dc57e8c7 because it
broke a few bots.

I made changes so that cmake checks whether some of the flags are
supported by the compiler that is used before adding them to the list.
Also, I moved function add_security_warnings to CompilerRTUtils.cmake so
that it is defined before it's used.

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

KCFI sanitizer

The KCFI sanitizer, enabled with `-fsanitize=kcfi`, implements a
forward-edge control flow integrity scheme for indirect calls. It
uses a !kcfi_type metadata node to attach a type identifier for each
function and injects verification code before indirect calls.

Unlike the current CFI schemes implemented in LLVM, KCFI does not
require LTO, does not alter function references to point to a jump
table, and never breaks function address equality. KCFI is intended
to be used in low-level code, such as operating system kernels,
where the existing schemes can cause undue complications because
of the aforementioned properties. However, unlike the existing
schemes, KCFI is limited to validating only function pointers and is
not compatible with executable-only memory.

KCFI does not provide runtime support, but always traps when a
type mismatch is encountered. Users of the scheme are expected
to handle the trap. With `-fsanitize=kcfi`, Clang emits a `kcfi`
operand bundle to indirect calls, and LLVM lowers this to a
known architecture-specific sequence of instructions for each
callsite to make runtime patching easier for users who require this
functionality.

A KCFI type identifier is a 32-bit constant produced by taking the
lower half of xxHash64 from a C++ mangled typename. If a program
contains indirect calls to assembly functions, they must be
manually annotated with the expected type identifiers to prevent
errors. To make this easier, Clang generates a weak SHN_ABS
`__kcfi_typeid_<function>` symbol for each address-taken function
declaration, which can be used to annotate functions in assembly
as long as at least one C translation unit linked into the program
takes the function address. For example on AArch64, we might have
the following code:

```
.c:
  int f(void);
  int (*p)(void) = f;
  p();

.s:
  .4byte __kcfi_typeid_f
  .global f
  f:
    ...
```

Note that X86 uses a different preamble format for compatibility
with Linux kernel tooling. See the comments in
`X86AsmPrinter::emitKCFITypeId` for details.

As users of KCFI may need to locate trap locations for binary
validation and error handling, LLVM can additionally emit the
locations of traps to a `.kcfi_traps` section.

Similarly to other sanitizers, KCFI checking can be disabled for a
function with a `no_sanitize("kcfi")` function attribute.

Relands 67504c95494ff05be2a613129110c9bcf17f6c13 with a fix for
32-bit builds.

Reviewed By: nickdesaulniers, kees, joaomoreira, MaskRay

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

{RISCV] Backout cttz/ctlz instruction costs

Craig points out correctly in post-commit review that these depend on the availability of floating point extensions.

[mlir][tosa] Add constant folding for tosa.slice

If the input to a tosa.slice operation is a splat we can just replace with
another splat. If the result is a single element, replacing with a splat
is universally useful.

Reviewed By: NatashaKnk

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

[RISCV] Pre-commit tests for D132614. NFC

[Flang] Enable lowering of CONVERT specifier in OPEN statements

The runtime function was implemented and tested and the
specifier was handled, but it seems lowering was never
specifically added.

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

[mlir][tosa] Added folders for tosa.add

Added folders for tosa.add that handles bypassing add-zero,
fold additions of two splat tensors, and additions between
two tensors with small values.

Reviewed By: jpienaar

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

[RISCV] Add empirical costs for bswap/bitreverse/ctpop/ctlz/cttz

If anyone is looking for a source of ideas on vector codegen improvements, the lowerings for several of these seem to include pretty obvious fixits.

[RISCV] Add cost model coverage for integer bitmanip intrinsics

[AST] Use std::apply to pop front of tuples. NFCI.

[InstCombine] use isa instead of dyn_cast for unused value; NFC

[lld-macho][test] Check addresses in flat-namespace-interposable.s

This test helped me catch an issue in my implementation of chained
fixups (D132560). This commit makes the test more robust by checking if
the bind opcodes are emitted for the correct address.

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

[flang] Fix msvc 17.3 build.

Compile fix for Microsoft Visual Studio 17.3 (msvc 14.33.31629) which regressed from 17.1.

The compile error is:
```
llvm-project\flang\lib\Evaluate\fold-integer.cpp(802,41): error C2672: 'invoke': no matching overloaded function found
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\include\type_traits(1552,19): message : could be 'unknown-type std::invoke(_Callable &&,_Ty1 &&,_Types2 &&...) noexcept(<expr>)'
llvm-project\flang\lib\Evaluate\fold-integer.cpp(802,41): message : Failed to specialize function template 'unknown-type std::invoke(_Callable &&,_Ty1 &&,_Types2 &&...) noexcept(<expr>)'
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\include\type_traits(1552): message : see declaration of 'std::invoke'
llvm-project\flang\lib\Evaluate\fold-integer.cpp(490,1): message : With the following template arguments:
llvm-project\flang\lib\Evaluate\fold-integer.cpp(490,1): message : '_Callable=int (__cdecl Fortran::evaluate::value::Integer<16,true,16,unsigned short,unsigned int>::* &)(void) const'
llvm-project\flang\lib\Evaluate\fold-integer.cpp(490,1): message : '_Ty1=const Fortran::evaluate::value::Integer<8,true,8,unsigned char,unsigned short> &'
llvm-project\flang\lib\Evaluate\fold-integer.cpp(490,1): message : '_Types2={}'
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\include\type_traits(1546,19): message : or       'unknown-type std::invoke(_Callable &&) noexcept(<expr>)'
C:\Users\meinersbur\src\llvm-project\flang\lib\Evaluate\fold-integer.cpp(802,41): message : 'unknown-type std::invoke(_Callable &&) noexcept(<expr>)': expects 1 arguments - 2 provided
```

For some reason, msvc thinks that the lambda argument is `Scalar<T>` instead of `Scalar<TI>` as declared. This only happens in nested closures, using a lambda without `[]` arguments makes the problem disappear. Using `auto` instead to automatically derive the type fixes the problem.

I recently updated the version of Visual Studio on [[ https://lab.llvm.org/buildbot/#/builders/172 | flang-x86_64-windows buildbot  ]] which since then fails because of this problem. It occasionally failed with 'fatal error C1001: Internal compiler error." internal error which I hoped to fix with an update.

Reviewed By: klausler

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

[lldb] Remove obsolete Android-specific definitions

Bionic's <sys/procfs.h> defines the necessary symbols.  Remove the
specialization for Android and the now-unnecessary include of
<sys/ptrace.h>.  This also helps resolve issues when building the
x86/x86_64 lldb-server for Android.

Curiously, the default branch to include <sys/procfs.h> doesn't seem
necessary on Linux.  I'll remove it and add it back if it breaks other
builders.

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

[gn build] Port 91389000abe8

[LLDB] Add data formatter for std::coroutine_handle

This patch adds a formatter for `std::coroutine_handle`, both for libc++
and libstdc++. For the type-erased `coroutine_handle<>`, it shows the
`resume` and `destroy` function pointers. For a non-type-erased
`coroutine_handle<promise_type>` it also shows the `promise` value.

With this change, executing the `v t` command on the example from
https://clang.llvm.org/docs/DebuggingCoroutines.html now outputs

```
(task) t = {
  handle = coro frame = 0x55555555b2a0 {
    resume = 0x0000555555555a10 (a.out`coro_task(int, int) at llvm-example.cpp:36)
    destroy = 0x0000555555556090 (a.out`coro_task(int, int) at llvm-example.cpp:36)
  }
}
```

instead of just

```
(task) t = {
  handle = {
    __handle_ = 0x55555555b2a0
  }
}
```

Note, how the symbols for the `resume` and `destroy` function pointer
reveal which coroutine is stored inside the `std::coroutine_handle`.
A follow-up commit will use this fact to infer the coroutine's promise
type and the representation of its internal coroutine state based on
the `resume` and `destroy` pointers.

The same formatter is used for both libc++ and libstdc++. It would
also work for MSVC's standard library, however it is not registered
for MSVC, given that lldb does not provide pretty printers for other
MSVC types, either.

The formatter is in a newly added  `Coroutines.{h,cpp}` file because there
does not seem to be an already existing place where we could share
formatters across libc++ and libstdc++. Also, I expect this code to grow
as we improve debugging experience for coroutines further.

**Testing**

* Added API test

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

[clang][modules] Consider M affecting after mapping M.Private to M_Private

When Clang encounters `@import M.Private` during implicit build, it precompiles module `M` and looks through its submodules. If the `Private` submodule is not found, Clang assumes `@import M_Private`. In the dependency scanner, we don't capture the dependency on `M`, since it's not imported. It's an affecting module, though: compilation of the import statement will fail when implicit modules are disabled and `M` is not precompiled and explicitly provided. This patch fixes that.

Depends on D132430.

Reviewed By: benlangmuir

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

[RISCV] Add empirically measured vector sqrt intrinsic costs

[RISCV] Add cost model coverage for floating point sqrt intrinsic

[MLIR] Generalize/complete getEnclosingAffineForIfOps utility

Rename/generalize getEnclosingAffineForIfOps -> getEnclosingAffineOps.
The utility was originally written only for affine.for ops and then
extended for affine.if as well. It wasn't however updated when
affine.parallel was introduced -- in most cases, analysis has been used
in the presence of affine.for/if but not post parallelization. Extend
utility to also support affine.parallel ops; this allows future changes
to enable affine analysis and opts in the presence of affine.parallel
ops. Fix related stale comments.

This is NFC for all use cases in tree.

Change an associated assert to a utility failure.

Reviewed By: ftynse

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

[lldb] Remove unused functions in ObjectContainer (NFC)

[RISCV] Add vector fabs intrinsic costs

We have a fabs vector instruction, and are using it for current lowering.

[flang] Noncontiguous formats

Add the remaining pieces to support IO for noncontigous formats.
This is done by passing an array descriptor to IO calls.  Scalar
formats continue to pass string and length arguments.  IO calls
with formats are modified to place the new format descriptor
argument directly after the original string and length arguments.

[SPIRV] support builtin functions

The patch adds support for OpenCL and SPIR-V built-in functions.
Their detection and properties are implemented using TableGen.
Five tests are added to demonstrate the improvement.

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

Co-authored-by: Aleksandr Bezzubikov <zuban32s@gmail.com>
Co-authored-by: Michal Paszkowski <michal.paszkowski@outlook.com>
Co-authored-by: Andrey Tretyakov <andrey1.tretyakov@intel.com>
Co-authored-by: Konrad Trifunovic <konrad.trifunovic@intel.com>

Add MachO MH_FILESET support to objdump

https://reviews.llvm.org/D131909

RISCV: permit unaligned nop-slide padding emission

We may be requested to emit an unaligned nop sequence (e.g. 7-bytes or
3-bytes).  These should be 0-filled even though that is not a valid
instruction.  This matches the behaviour on other architectures like
ARM, X86, and MIPS.  When a custom section is emitted, it may be
classified as text even though it may be a data section or we may be
emitting data into a text segment (e.g. a literal pool).  In such cases,
we should be resilient to the emission request.

This was originally identified by the Linux kernel build and reported on
D131270 by Nathan Chancellor.

Differential Revision: https://reviews.llvm.org/D132482
Reviewed By: luismarques
Tested By: Nathan Chancellor

[GlobalOpt] Bail out of GlobalOpt SROA if a Scalable Vector is seen

The SROA algorithm won't work for Scalable Vectors, since we don't
know how many bytes are loaded/stored. Bail out if a Scalable
Vector is seen.

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

[InstCombine] reduce disguised mul+add factorization

~(A * C1) + A --> (A * (1 - C1)) - 1

This is a non-obvious mix of bitwise logic and math:
https://alive2.llvm.org/ce/z/U7ACVT

The pattern may be produced by Negator from the more typical
code seen in issue #57255.

[InstCombine] add tests for add with not-of-mul common operand; NFC

Negator can create non-obvious math while trying hard to avoid subtraction.
issue #57255

Exclude check-polly-unittests and check-polly-isl from check-all

The unittests are already included in check-polly, so check-all was
running them twice.  Running them twice causes a race on the output
files, which led to intermittent failures on the reverse-iteration
buildbot.

[HLSL] Entry functions require param annotation

HLSL entry function parameters must have parameter annotations. This
allows appropriate intrinsic values to be populated into parameters
during code generation.

This does not handle entry function return values, which will be
handled in a subsequent commit because we don't currently support any
annotations that are valid for function returns.

Reviewed By: aaron.ballman

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

[libomptarget][amdgpu] enable tests whenever possible.

if(TARGET amdgpu-arch) doesn't work when ENABLE_LLVM_PROJECTS=openmp because openmp subdirectory is processed before clang subdirectory. Adopt the same logic of enabling tests like the CUDA plugin.

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

Revert "KCFI sanitizer"

This reverts commit 67504c95494ff05be2a613129110c9bcf17f6c13 as using
PointerEmbeddedInt to store 32 bits breaks 32-bit arm builds.

[LoongArch] Fix build due to TLI interface changes. NFC.

- isCheapToSpeculateCttz/isCheapToSpeculateCtlz have one type operand
  after https://reviews.llvm.org/D132520

[Flang][OpenMP] Add support for safelen clause

This supports lowering from parse-tree to MLIR for OpenMP safelen clause
in SIMD construct.

Reviewed By: kiranchandramohan

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

KCFI sanitizer

The KCFI sanitizer, enabled with `-fsanitize=kcfi`, implements a
forward-edge control flow integrity scheme for indirect calls. It
uses a !kcfi_type metadata node to attach a type identifier for each
function and injects verification code before indirect calls.

Unlike the current CFI schemes implemented in LLVM, KCFI does not
require LTO, does not alter function references to point to a jump
table, and never breaks function address equality. KCFI is intended
to be used in low-level code, such as operating system kernels,
where the existing schemes can cause undue complications because
of the aforementioned properties. However, unlike the existing
schemes, KCFI is limited to validating only function pointers and is
not compatible with executable-only memory.

KCFI does not provide runtime support, but always traps when a
type mismatch is encountered. Users of the scheme are expected
to handle the trap. With `-fsanitize=kcfi`, Clang emits a `kcfi`
operand bundle to indirect calls, and LLVM lowers this to a
known architecture-specific sequence of instructions for each
callsite to make runtime patching easier for users who require this
functionality.

A KCFI type identifier is a 32-bit constant produced by taking the
lower half of xxHash64 from a C++ mangled typename. If a program
contains indirect calls to assembly functions, they must be
manually annotated with the expected type identifiers to prevent
errors. To make this easier, Clang generates a weak SHN_ABS
`__kcfi_typeid_<function>` symbol for each address-taken function
declaration, which can be used to annotate functions in assembly
as long as at least one C translation unit linked into the program
takes the function address. For example on AArch64, we might have
the following code:

```
.c:
  int f(void);
  int (*p)(void) = f;
  p();

.s:
  .4byte __kcfi_typeid_f
  .global f
  f:
    ...
```

Note that X86 uses a different preamble format for compatibility
with Linux kernel tooling. See the comments in
`X86AsmPrinter::emitKCFITypeId` for details.

As users of KCFI may need to locate trap locations for binary
validation and error handling, LLVM can additionally emit the
locations of traps to a `.kcfi_traps` section.

Similarly to other sanitizers, KCFI checking can be disabled for a
function with a `no_sanitize("kcfi")` function attribute.

Reviewed By: nickdesaulniers, kees, joaomoreira, MaskRay

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

[libc] Add linux implementation of POSIX fchmodat function.

Reviewed By: michaelrj

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

[LV] Simplify code given isPredicatedInst doesn't dependent on VF any more [nfc]

[RISCV][LV] Add predicated div/rem test for fixed length vectorization

[SLP][NFC] Add test case exposing deficiency in finding reductions that feed buildvector sequence.

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

[clang][modules] Track affecting modules

When compiling a module, its semantics and Clang's behavior are affected by other modules. These modules are typically the **imported** ones. However, during implicit build, some modules end up being compiled and read without being actually imported. This patch starts tracking such modules and serializing them into `.pcm` files. This enables the dependency scanner to construct explicit compilations that mimic implicit build.

Reviewed By: benlangmuir

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

[LV] Update a test which appears to have been editted without regen [nfc]

Revert "[BOLT] Towards FunctionLayout const-correctness"

This reverts commit 587d2653420d75ef10f30bd612d86f1e08fe9ea7.

Revert "[BOLT] Allocate FunctionFragment on heap"

This reverts commit 101344af1af82d1633c773b718788eaa813d7f79.

Revert "[BOLT] Track fragment info for all split fragments"

This reverts commit 7e254818e49454a53bd00e3737007025b62d0f79.

[LV] Adjust code added in f79214d1 for 531dd3634 [nfc]

When rebasing the review which became f79214d1, I forgot to adjust for the changed semantics introduced by 531dd3634.  Functionally, this had no impact, but semantically it resulted in an incorrect result for isPredicatedInst.  I noticed this while doing a follow up change.

[Clang] Avoid using unwind library in the MSVC environment

We're seeing the following warnings with --rtlib=compiler-rt:

  lld-link: warning: ignoring unknown argument '--as-needed'
  lld-link: warning: ignoring unknown argument '-lunwind'
  lld-link: warning: ignoring unknown argument '--no-as-needed'

MSVC doesn't use the unwind library, so just omit it.

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

[llvm-objdump] Complete -chained_fixups support

This commit adds definitions for the `dyld_chained_import*` structs.
The imports array is now printed with `llvm-otool -chained_fixups`. This
completes this option's implementation.

A slight difference from cctools otool is that we don't yet dump the
raw bytes of the imports entries.

When Apple's effort to upstream their chained fixups code continues,
we'll replace this code with the then-upstreamed code. But we need
something in the meantime for testing ld64.lld's chained fixups code.

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

[libc] move printf to use StringViews

The FormatSection and the writer functions both previously took a char*
and a length to represent a string. Now they use the StringView class to
represent that more succinctly. This change also required fixing
everywhere these were used, so it touches a lot of files.

Reviewed By: sivachandra

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

[libc++] Tests transitive includes for all C++ versions.

D132284 has an approach to reduce the number of transitive includes
based on the language version used. This requires to be able to validate
changes in transitive includes in all language versions.

Due to issues in the experimental library c++03 will be done separately.

Reviewed By: #libc, ldionne

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

[BOLT] Track fragment info for all split fragments

To generate all symbols correctly, it is necessary to record the address
of each fragment. This patch moves the address info for the main and
cold fragments from BinaryFunction to FunctionFragment, where this data
is recorded for all fragments.

Reviewed By: rafauler

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

[BOLT] Allocate FunctionFragment on heap

This changes `FunctionFragment` from being used as a temporary proxy
object to access basic block ranges to a heap-allocated object that can
store fragment-specific information.

Reviewed By: rafauler

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

[BOLT] Towards FunctionLayout const-correctness

A const-qualified reference to function layout allows accessing
non-const qualified basic blocks on a const-qualified function. This
patch adds or removes const-qualifiers where necessary to indicate where
basic blocks are used in a non-const manner.

Reviewed By: rafauler

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

[mlir] Support llvm.readnone attribute for all FunctionOpInterface ops.

The attribute is translated into LLVM's function attribute 'readnone'.
There is no explicit verification regarding conflicting 'readnone'
and function attributes from 'passthrough', though, LLVM would assert
if they are incompatible during LLVM IR creation.

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

[LV] Support predicated div/rem operations via safe-divisor select idiom

This patch adds support for vectorizing conditionally executed div/rem operations via a variant of widening. The existing support for predicated divrem in the vectorizer requires scalarization which we can't do for scalable vectors.

The basic idea is that we can always divide (take remainder) by 1 without executing UB. As such, we can use the active lane mask to conditional select either the actual divisor for active lanes, or a constant one for inactive lanes. We already account for the cost of the active lane mask, so the only additional cost is a splat of one and the vector select. This is one of several possible approaches to this problem; see the review thread for discussion on some of the others.  This one was chosen mostly because it was straight forward, and none of the others seemed oviously better.

I enabled the new code only for scalable vectors. We could also legally enable it for fixed vectors as well, but I haven't thought through the cost tradeoffs between widening and scalarization enough to know if that's profitable. This will be explored in future patches.

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

[VPlan] Remove unneeded `struct` prefix for VPTransformState args (NFC).

extending code layout alg

The diff modifies ext-tsp code layout algorithm in the following ways:
(i) fixes merging of cold block chains (this is a port of D129397);
(ii) adjusts the cost model utilized for optimization;
(iii) adjusts some APIs so that the implementation can be used in BOLT; this is
a prerequisite for D129895.

The only non-trivial change is (ii). Here we introduce different weights for
conditional and unconditional branches in the cost model. Based on the new model
it is slightly more important to increase the number of "fall-through
unconditional" jumps, which makes sense, as placing two blocks with an
unconditional jump next to each other reduces the number of jump instructions in
the generated code. Experimentally, this makes a mild impact on the performance;
I've seen up to 0.2%-0.3% perf win on some benchmarks.

Reviewed By: hoy

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