Mirror of the previous log changes, OpenCL conformance doesn't like
interpreting afn as ignore denormal handling but was previously hidden
by flag dropping.

(cherry picked from commit 81b278e6)

OpenCL conformance didn't like interpreting afn as ignore the denormal
handling.

https://reviews.llvm.org/D157940
(cherry picked from commit 4b7b4b94)

Apparently afn doesn't allow you to drop the denormal handling
according to OpenCL conformance. This was hidden by losing the flags
during the library linking process. Fast log is still broken and needs
more work.

https://reviews.llvm.org/D157936
(cherry picked from commit e09b3593)

We should query the subtarget of the calling function, not of the
intrinsic.

This probably makes no functional difference (as libcalls are
unlikely to vary across subtargets), but fixes minor compile-time
regressions from unnecessary subtarget instantiations.

Followup to D157567.

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

(cherry picked from commit 66bb7521)

We need a better mechanism for expressing which calls you are allowed
to emit and which calls are recognized. This should be applied to the
17 branch.

(cherry picked from commit c8cac156)

PSTL contains many pragmas that request loop vectorization, which would
produce a warning when the compiler is unable to fulfill the request (if
`-Wpass-failed` is enabled). This is normal and expected in some cases,
and we don't want `-Werror` to turn that into a compilation failure.

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

(cherry picked from commit 1d340250)

[SelectionDAG] Use TypeSize variant of ComputeValueVTs to compute correct offsets for scalable aggregate types.

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

Some prep work to make aggregate loads and stores TypeSize aware.

Patch also includes a minor fix to AArch64::isLegalAddressingMode
to ensure all scalable types have a suitable bailout.

The subtarget was unconditionally reporting that SVE was to be used to
lower vectors when Neon was unavailable, even when SVE itself was
unavailable. This decision leads other parts of the compiler to crash,
e.g., when querying SVE vector sizes.

Reviewed By: sdesmalen

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

(cherry picked from commit c058eb99)

Previously when objcopy generated section headers, it padded the LEB
that encodes the section size out to 5 bytes, matching the behavior of
clang. This is correct, but results in a binary that differs from the
input. This can sometimes have undesirable consequences (e.g. breaking
source maps).

This change makes the object reader remember the size of the LEB
encoding in the section header, so that llvm-objcopy can reproduce it
exactly. For sections not read from an object file (e.g. that
llvm-objcopy is adding itself), pad to 5 bytes.

Reviewed By: jhenderson

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

(cherry picked from commit 1b21067c)

FRINT was added to matchRoundingOp after this function was written.
So FRINT was not tested originally.

For vectors, folding this causes us to create a CSR swap that tries
to write 7 to FRM. This is an illegal value and will cause the CSR
write to fail.

While this might be a legal fold we could do, I'm disabling it for
now so we can backport to LLVM 17 with the least risk.

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

(cherry picked from commit 2df9328f)

Relative to the previous attempt, this also adjusts RegionInfo
verification to allow unreachable predecessors.

-----

If a block in the CHR region has an unreachable predecessor, then
there will be no edge from that predecessor to the newly cloned
block. However, a phi node entry for it will be left behind. Make
sure that these incoming blocks get dropped as well.

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

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

(cherry picked from commit 7e2f1ae7)

This reverts commit 985486dc.

This seems to cause malformed profdata: crbug.com/1469456

(cherry picked from commit 4b08be77)

I don't have a test case for this but noticed this warning when including system headers with `-I` rather than `-isystem`.

```
In file included from <built-in>:1:
In file included from /nix/store/jq6bpm0xmhnbffhs5rkxq4n88g5xi2zg-clang-wrapper-11.0.1/resource-root/include/__clang_cuda_runtime_wrapper.h:157:
/nix/store/jq6bpm0xmhnbffhs5rkxq4n88g5xi2zg-clang-wrapper-11.0.1/resource-root/include/__clang_cuda_math.h:39:25: warning: extra tokens at end of #ifdef directive [-Wextra-tokens]
                        ^
```

Reviewed By: tra

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

(cherry picked from commit c49142e4)

In a standalone build, there is no guarantee that flang code would be
saved in a directory named flang. Check only the path under flang's root
directory.

Reviewed By: #flang, kiranchandramohan

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

(cherry picked from commit 94f377d8)

An empty struct is handled as a struct with a dummy i8, on all targets.

Most targets treat an empty struct return value as essentially
void - but some don't. (Currently, at least x86_64-windows-* and
powerpc64le-* don't treat it as void.)

When intializing a struct with such a no_unique_address member,
make sure we don't write the dummy i8 into the struct where there's
no space allocated for it.

Previously it would clobber the actual valid data of the struct.

Fixes https://github.com/llvm/llvm-project/issues/64253, and
possibly https://github.com/llvm/llvm-project/issues/64077
and https://github.com/llvm/llvm-project/issues/64427 as well.

We should omit the store for any empty record (not only ones
declared with no_unique_address); we can have a situation where a
class doesn't have the no_unique_address attribute, but is embedded
in an outer struct with the no_unique_address attribute - like this:

    struct S {};
    S f();
    struct S2 : public S { S2();};
    S2::S2() : S(f()) {}
    struct S3 { int x; [[no_unique_address]] S2 y; S3(); };
    S3::S3() : x(1), y() {}

Here, the problematic store (which this patch omits) is in
the constructor of S2. In the case of S3, S2 has no valid storage
and aliases x - thus the constructor of S2 should omit the dummy
store.

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

(cherry picked from commit d60c3d08)

Check iterator validity before use; fixes a crash seen in the RISC-V
Zcmp Push/Pop optimization pass when compiling an internal benchmark.

Reviewed By: asb, wangpc

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

(cherry picked from commit 53e89f5e)

This adds a RISC-V special case to ToolChain::GetDefaultDwarfVersion,
affecting Linux/Haiku/RISCVToolChain.

DWARF v5 .debug_loclists/.debug_rnglists's
DW_LLE_offset_pair/DW_RLE_offset_pair entry kinds utilitize `.uleb128 A-B`
directives where A and B reference local labels in code sections.
When A and B are separated by a RISC-V linker-relaxable instruction,
A-B is incorrectly folded without a relocation, causing incorrect debug
information.

```
void ext(void);
int foo(int x) {ext(); return 0;}
// DW_AT_location [DW_FORM_loclistx] of a DW_TAG_formal_parameter references a DW_LLE_offset_pair that can be incorrect after linker relaxation.

int ext(void);
void foo() { {
  int ret = ext();
  if (__builtin_expect(ret, 0))
    ext();
} }
// DW_AT_ranges [DW_FORM_rnglistx] of a DW_TAG_lexical_block references a DW_RLE_offset_pair that can be incorrect after linker relaxation.
```

D157657 will implement R_RISCV_SET_ULEB128/R_RISCV_SUB_ULEB128
relocations, fixing the issue, but the relocation is only supported by
bleeding-edge binutils 2.41 and not by lld/ELF yet.

The goal is to make the emitted DWARF correct after linking.
Many users don't care about the default DWARF version, but a linker
error will be unacceptable. Let's just downgrade the default DWARF
version, before binutils>=2.41 is more widely available.

An alternative compatibility option is to add a toggle to DwarfDebug.cpp,
but that doesn't seem like a good idea.

Reviewed By: asb, kito-cheng

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

(cherry picked from commit bbc0f99f)
(with a release note)

Fix crash when diagnostic is emit with invalid location,
but with attached valid ranges. Diagnostic can contain
invalid location, but SourceManager attached to it still
can be valid, use it in such case or fallback to known
SourceManager.

Fixes: #64602

Reviewed By: aaron.ballman

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

(cherry picked from commit efd44f80)

This reverts commit d031ff38.
See https://reviews.llvm.org/D154503#4576393 for a reproducer and
details.

(cherry picked from commit 7d259b36)

This issue was raised on https://github.com/llvm/llvm-project/issues/64268.

`flang/lib/Optimizer/Transforms/SimplifyIntrinsics.cpp` includes
`flang/Optimizer/HLFIR/HLFIRDialect.h` and might fails if the HLFIR related
tablegen files have not been generated.

Reviewed By: vzakhari

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

(cherry picked from commit 103907bc)

D141386 changed the semantics of !range metadata to return poison
on violation. If !range is combined with !noundef, violation is
immediate UB instead, matching the old semantics.

In theory, these IR semantics should also carry over into SDAG.
In practice, DAGCombine has at least one key transform that is
invalid in the presence of poison, namely the conversion of logical
and/or to bitwise and/or (https://github.com/llvm/llvm-project/blob/c7b537bf0923df05254f9fa4722b298eb8f4790d/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp#L11252).
Ideally, we would fix this transform, but this will require
substantial work to avoid codegen regressions.

In the meantime, avoid transferring !range metadata without
!noundef, effectively restoring the old !range metadata semantics
on the SDAG layer.

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

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

(cherry picked from commit 9deee6bf)

(cherry picked from commit 59d558a3)

The function changeVectorElementType assumes MVT input types will
result in MVT output types.  There's no gurantee this is possible
during early code generation and so this patch converts an instance
used during initial DAG construction to instead explicitly create a
new EVT.

NOTE: I could have added more MVTs, but that seemed unscalable as
you can either have MVTs with 100% element count coverage or 100%
bitwidth coverage, but not both.

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

(cherry picked from commit b7e6e568)

This reverts commit 8981520b.

See discussion in https://github.com/llvm/llvm-project/issues/64225

Differential https://reviews.llvm.org/D145477 removed the check for `(yaml and args.export_fixes)` in line 303 to skip looking for the `clang-apply-replacements` binary. However, the `tmpdir` variable was set in this true branch when exporting fixes and therefore is `None` when invoking run-clang-tidy with `run-clang-tidy -p . -export-fixes fixes.yaml`.

Reviewed By: PiotrZSL

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

(cherry picked from commit c3da9927)

When compiling Rust code we may end up with calls to functions provided
by other code units. Presently this code crashes on a null pointer
dereference - this patch avoids that crash and adds a test.

Reviewed By: ast

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

(cherry picked from commit 055893be)

This was an oversight when the GFX11 early release VGPRs optimization
was reimplemented in D153279.

Sending the DEALLOC_VGPRS message is a performance optimization so there
is no need to do it at -O0. In addition it makes some kinds of post
mortem debugging hard or impossible, since VGPR values are no longer
available to inspect at the s_endpgm instruction.

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

(cherry picked from commit 3091bdb8)

We need unsigned integer here.

Fixes #64534

Reviewed By: eopXD

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

(cherry picked from commit 5a3753f3)

Since GCC 11, the bundled Solaris/SPARC GCC uses the `sparcv8plus`
subdirectory for 32-bit objects, just like upstream GCC.  Before that, it
used `32` instead from a local patch.

Since `clang` doesn't know about that `sparcv8plus` subdirectory, it
wouldn't properly use GCC 11+ installations.

The new `solaris-sparc-gcc-search.test` testcase wasn't run initially (like
the existing `crash-report-null.test`) because the `.test` suffix wasn't
handled.

Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.

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

(cherry picked from commit 43dfe0f0)

* 4d494e76: Handle static_assert messages with an expression started by a literal
* 49e0495f Produce a warning instead of an error in unevaluated strings before C++26

Emiting an error on unexpected encoding prefix - which was allowed before C++26 -
caused build errors for a few users.
This downgrade the error to a warning on older language modes and C

`R_LARCH_PCREL20_S2` is a new added relocation type in LoongArch ELF
psABI v2.10 [1] which is not corvered by D138135 except `R_LARCH_64_PCREL`.

A motivation to support `R_LARCH_PCREL20_S2` in lld is to build the
runtime of .NET core (a.k.a `CoreCLR`) in which strict PC-relative
semantics need to be guaranteed [2]. The normal `pcalau12i + addi.d`
approach doesn't work because the code will be copied to other places
with different "page" and offsets. To achieve this, we can use `pcaddi`
with explicit `R_LARCH_PCREL20_S2` reloc to address +-2MB PC-relative
range with 4-bytes aligned.

[1]: https://github.com/loongson/la-abi-specs/releases/tag/v2.10
[2]: https://github.com/dotnet/runtime/blob/release/7.0/src/coreclr/vm/loongarch64/asmhelpers.S#L307

Reviewed By: xen0n, MaskRay

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

(cherry picked from commit 8a31f7dd)

When generating unwind tables for code which uses return-address
signing, we need to toggle the RA_SIGN_STATE DWARF register around any
tail-calls, because these require the return address to be authenticated
before the call, and could throw an exception. This is done using the
.cfi_negate_ra_state directive before the call, and .cfi_restore_state
at the start of the next basic block.

However, since D153098, the .cfi_restore_state isn't being inserted,
because the CFIFixup pass isn't being run. This re-enables that pass
when return-adress signing is enabled.

Reviewed By: ikudrin, MaskRay

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

(cherry picked from commit f2e7285b)

Using implicit CHECK prefix in one FileCheck invocation and explicit
CHECK-V83A in the other one seems to misguide to use CHECK: lines as
a common matching prefix at various places. Also note that

; CHECK, CHECK-V83A: ...

line only matches the "CHECK-V83A" prefix.

This commit explicitly splits the checks into common ones (CHECK) and
invocation-specific ones (COMPAT and V83A) and updates the assertions
with the update_llc_test_checks.py script.

Reviewed By: efriedma, MaskRay

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

(cherry picked from commit 4210204f)

Set the ReplaceFlags variable to false, since there is code meant only
for the ADDItocHi/ADDItocL nodes. This has the side effect of disabling
the peephole when the load/store instruction has a non-zero offset.
This patch also fixes retrieving the `ImmOpnd` node from the AIX small
code model pseduos and does the same for the register operand node.
This allows cleaning up the later calls to replaceOperands.
Finally move calculating the MaxOffset into the code guarded by
ReplaceFlags as it is only used there and the comment is specific to the ELF
ABI.

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

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

(cherry picked from commit b37c7ed0)

There are cases where the -1 doesn't become visible until lowering
so the folding doesn't have a chance to run.

I think in these cases there is a missed DAGCombine for truncate (undef),
which I may fix separately, but RISC-V backend should protect itself.

Fixes #64503.

Reviewed By: asb

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

(cherry picked from commit 7cc61541)

The llvm-rc tool tries to locate a suitable Clang executable to
use for preprocessing. For this purpose, it first checks within
the same directory as the llvm-rc tool, checking with a couple
different names, followed by checking all of $PATH for another
couple names.

On Windows, the InitLLVM() function always sets up Argv[0] with the
full path to the executable, while on Unix, Argv[0] is kept as is.

Therefore, call getMainExecutable to try to resolve the directory of
the executable before looking for colocated Clang executables.

This makes 282744a9 actually have
the desired effect.

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

(cherry picked from commit 8c6a0c8b)