Created using spr 1.3.4

Semantics is emitting an error when an actual argument to a procedure
that has an implicit interface has a polymorphic type. This is too
general; while TYPE(*) and CLASS(*) unlimited polymorphic items require
the presence of an explicit procedure interface, CLASS(T) data can be
passed over an implicit interface to a procedure expecting a
corresponding dummy argument with TYPE(T), so long as T is not
parameterized.

(Only XLF handles this usage correctly among other Fortran compilers.)

(Making this work in the case of an actual CLASS(T) array may well
require additional changes in lowering to copy data to/from a temporary
buffer to ensure contiguity when the actual type of the array is an
extension of T.)

This patch adds support for enter attribute in declare target. As the
enter attribute is a replacement for `to` attribute, it has the same
tests.

The semantics and encodings for these instructions are described by the
Hexagon V67 Programmer's Reference Manual:

https://developer.qualcomm.com/downloads/qualcomm-hexagon-v67-programmer-s-reference-manual

Opaque ptr cleanup effort (NFC).

Prior to this, clang would always report

```
compile with '-ffixed-point' to enable fixed point types
```

whenever it sees `_Accum`, `_Fract`, or `_Sat` when fixed point
arithmetic is not enabled. This can break existing code that uses these
as variable names and doesn't use fixed point arithmetic like in some
microsoft headers

(https://github.com/llvm/llvm-project/pull/67750#issuecomment-1775264907).

Fixed point should not raise this error for these cases, so this removes
the error altogether and defaults to the usual error clang gives where
it can see these keywords as either unknown types or regular variables.

In our default SelectionDAG where i32 isn't legal, the zext will become
and i64 AND and often get optimized out on its own. With i32 legal, we
need to turn it in into sext.w and rely on RISCVOptWInstrs to remove it.

Coerce the register bank based on the users of the G_LOAD or the
defining instruction for the G_STORE.

s64 on rv32 is handled by forcing the FPRB register bank.

…ffine subscript expressions.

This upstreams more of the Clang API Notes functionality that is
currently implemented in the Apple fork:
https://github.com/apple/llvm-project/tree/next/clang/lib/APINotes

This patch extracts the logic to create a static variable member decl
into a helper. We will use this in an upcoming patch which will need to
call exactly the same logic from a separate part of the DWARF parser.

The base ISA does not support these operations. A future patch will
enable them for Zbb.

Refine FIXMEs in added tests, the problematic case only materializes if
there's either both a read and write from an indirect address.

GCC is able to check that the signatures of the builtins are as expected
and this shows some incorrect signatures on ld80 platforms (i.e. x86).
The *tf* functions should take 128-bit arguments but until the latest fixes
they used 80-bit long double.

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

The DWARF 5 specification says that:

> The name index must contain an entry for each debugging information
entry that
> defines a named [...] label [...].

The verifier currently verifies this, but the AsmPrinter does not add
entries for TAG_labels in debug_names. This patch addresses the issue by
ensuring we add labels in the accelerator tables once we have a fully
completed DIE for the TAG_label entry.

We also respect the spec as follows:
> DW_TAG_label debugging information entries without an address
attribute
> (DW_AT_low_pc, DW_AT_high_pc, DW_AT_ranges, or DW_AT_entry_pc) are
excluded.

The effect of this on the size of accelerator tables is minimal, as
TAG_labels are usually created by C/C++ labels (see example in test),
which are typically paired with "goto" statements.

When serializing to bytecode, users can select the option to elide
resources from the bytecode file. This will instruct the bytecode writer
to serialize only the key and resource kind, while skipping
serialization of the data buffer. At parsing, the IR is built in memory
with valid (but empty) resource handlers.

This patch clarifies the documentation of methods `inferReturnTypeComponents()`
and `inferReturnTypes()` regarding verified/valid arguments.

This changed while the ctpop patch was in review and I forgot to update it.

The base ISA does not have an instruction for this so we need to lower.
Zbb support will come in a future patch.

Enables reusing the AsmState when printing from Python. Also moves the
fileObject and binary to the end (pybind11::object was resulting in the
overload not working unless `state=` was specified).

---------

Co-authored-by: Maksim Levental <maksim.levental@gmail.com>

This method is completely unused.

Opaque ptr cleanup effort (NFC).

Note that the (dis)assemble operations still make some simplfying
assumptions (e.g. trailing 2-D COO in AoS format) but now at least both
the direct IR and support library path behave exactly the same.

Generalizing the ops is still TBD.

Test still fail on ARM machine (no float_control support)

Summary:
Add description to AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
for "DWARF Operations to Create Vector Composite Location Descriptions"
proposal to explain the main motivation is to facilitate more compact
DWARF that is faster to evaluate.

Reviewers: kzhuravl, scott.linder, zoran.zaric

Subscribers:

Most (x86) swiftasync functions tend to use both SelectionDAGISel and
FastISel lowering:
* FastISel argument lowering can only handle C calling convention.
* FastISel fails mid-BB in a number of ways, including in simple `ret
void` instructions under certain circumstances.

This dance of SelectionDAG (argument) -> FastISel (some instructions) ->
SelectionDAG(remaining instructions) is lossy; in particular, Argument
information lowering is cleared after that first SelectionDAG run.

Since swiftasync functions rely heavily on proper Argument lowering for
debug information, this patch disables the use of FastISel in such
functions.

[AArch64] Cast predicate operand of SVE gather loads/scater stores to the parameter type of the intrinsic (NFC) (#71289)

When emitting LLVM IR for gather loads/scatter stores, the predicate
parameter is cast to a type that depends on the loaded, resp. stored
type. That's correct for operation where we have a predicate per lane,
however it is not correct for quadword loads and stores (`LD1Q`, `ST1Q`)
where the predicate is per 128-bit chunk, independent from the ACLE
intrinsic type.

This can be universally handled by cast to the corresponding parameter
type of the intrinsic. The intrinsic itself should be defined in a way
that enforces relations between parameter types.

Based on the tips from @ubfx and @joker-eph in
https://github.com/llvm/llvm-project/issues/70030

, this patch suggest to
introduce the `dest` operand in the `tensor` dialect description. To do
so, this patch also suggests to move some things around to make it more
clear how the paragraphs relate to each other.

---------

Co-authored-by: Matthias Springer <me@m-sp.org>
Co-authored-by: Mehdi Amini <joker.eph@gmail.com>
Co-authored-by: Felix Schneider <fx.schn@gmail.com>

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

Identified with clangd.

Summray:
A recent patch upgrades the NVPTX ctor / dtor lowering pass to emit
kernels so other languages can call them. We do this manually in `libc`
so we do not need this. Use the provided flag to disable this step to
keep the created kernels cleaner.

Remove bitcast added back in dcd74716 .

instregex uses an optimization, where the constant prefix of the regex
is extracted to perform a binary search first. However, this
optimization currently mainly fails to apply, because most instregex
uses have an explicit ^ anchor, which gets counted as a meta char and
disables the optimization.

Make sure the anchor is skipped when determining the prefix. Also fix an
implementation bug this exposes, where the pick a too long prefix if the
first meta character is a quantifier.

This cuts the time needed to generate files like X86GenInstrInfo.inc by
half.

After #71534 and #72052, the transform `zext -> zext nneg` in
`RISCVCodeGenPrepare` is redundant.

PR #71614 identified an issue in the lowering of v1f16 vector compares,
where the `v1i1 setcc` is expanded to `v1i16 setcc`, and the `v1i16
setcc` tries to be expanded to a `v2i16 setcc` which fails. For floating
point types we can let them scalarize instead though, generating a
`setcc f16` that can be lowered using normal fp16 lowering.

07a8ff48 added a special case combine
for v1 vselect to expand the predicate type to the same size as the fcmp
operands. This turns that off for float types, allowing them to
scalarize naturally, which hopefully fixes the issue by preventing the
v1i16 setcc, meaning it wont try to widen to larger vectors.

The codegen might not be optimal, but as far as I can tell everything
generated successfully, providing that no `v1i16 setcc v1f16`
instructions get generated.

This patch infers `nneg` flags for existing zext instructions in CVP.
After https://github.com/llvm/llvm-project/pull/71534 and this patch, we
can drop `zext -> zext nneg` transform in `RISCVCodeGenPrepare`:


https://github.com/llvm/llvm-project/blob/40671bbdefb6ff83e2685576a3cb041b62f25bbe/llvm/lib/Target/RISCV/RISCVCodeGenPrepare.cpp#L74-L83

This is an alternative to #72049.

[SimplifyCFG] Prevent merging cbranch to cbranch if the branch probability from the first to second is too low. (#69375)

AMDGPU target has faced the situation which can be illustrated with the
following testcase:

define void @dont_merge_cbranches(i32 %V) {
  %divergent_cond = icmp ne i32 %V, 0
  %uniform_cond = call i1 @uniform_result(i1 %divergent_cond)
  br i1 %uniform_cond, label %bb2, label %exit, !prof !0
bb2:
  br i1 %divergent_cond, label %bb3, label %exit
bb3:
  call void @bar( )
  br label %exit
exit:
  ret void
}
!0 = !{!"branch_weights", i32 1, i32 100000}

SimplifyCFG merges branches on %uniform_cond and %divergent_cond which is undesirable because the first branch to bb2 is taken extremely rare and the second branch is expensive. The merged branch becomes as expensive as the second.

This patch prevents such merging if the branch to the second branch is unlikely to happen.