[X86] Use default attributes for intrinsics

This adds the default attributes (nocallback, nosync, nofree,
willreturn) to some X86 intrinsics. This will be needed to avoid
optimization regressions in the future (once we remove the
readonly -> willreturn implication for intrinsics).

Due to the number of intrinsics, this patch focuses just on the
IntrNoMem intrinsics up to the AVX2 section.

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

[mlir] Do not expose MLIRContext::isDialectLoading

This addresses post-commit comments and should have been part of D136685.

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

[docs] Add the description about mixing use of clang modules and c++
modules

From the discussion in
https://discourse.llvm.org/t/how-should-we-support-dependency-scanner-for-c-20-modules/66027,
we get a consensus that we want to support clang modules and c++ modules
at the same time. This patch documents this intention.

Reviewed By: bruno

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

Fix unused-variable warning in release build, NFC

[libc++] newlib/xlocale.h: remove redundant includes

This permits using the <locale> header with newlib or picolibc when
LIBCXX_ENABLE_WIDE_CHARACTERS=FALSE.

Since D136682 the __support/xlocale headers themselves include the
headers they require, respecting the LIBCXX_ENABLE_WIDE_CHARACTERS
option.

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

[lit][NFC] not check stdout in googletest-timeout.py

This is flicky for buildbots (for example, https://lab.llvm.org/buildbot/#/builders/188/builds/21560)
because of the short timeout. The test coverage is not reduced because
the stdout check is performed in other googtest-* unit tests.

[Clang] use non-instantiated function declaration for constraints partial ordering

Per wordings in
- https://eel.is/c++draft/over.match#best.general-2.6
- https://eel.is/c++draft/temp.constr.order
- https://eel.is/c++draft/temp.constr#atomic-1

constraints partial ordering should use the unsubstituted template
parameters of the constrained entity, not the instantiated entity.

Fix #56154

Reviewed By: erichkeane, royjacobson, mizvekov

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

[Clang] perform "maximum TLS alignment" check for template instantiation

follow up https://github.com/llvm/llvm-project/commit/d30e2eefc3cf8dfd2210aefd62f13a6e7c011b43

Reviewed By: mizvekov

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

[PowerPC] Optimize compare by using record form in post-RA.

Summary: We currently optimize the comparison only in SSA, therefore we will miss some optimization opportunities where the input of comparison is lowered from COPY in post-RA.
Ie. ExpandPostRA::LowerCopy is called after PPCInstrInfo::optimizeCompareInstr.
This patch optimizes the comparison in post-RA and only the cases that compare against zero can be handled.
D131374 converts the comparison and its user to a compare against zero with the appropriate predicate on the branch, which creates additional opportunities for this patch.

Reviewed By: shchenz, lkail

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

[JITLink][AArch64] Update edge names to be more descriptive, add comments.

This brings the aarch64 edges into alignment with the naming scheme for the
x86-64 edges.

Edge behavior is mostly unchanged, but some irrelevant assertions and errors
have been removed.

[LoongArch] Support inline asm operand modifier 'z'

Print $zero register if operand is zero, otherwise print it normally.

Clang is highly compatible [1] with GCC inline assembly extensions,
allowing the same set of constraints, modifiers and operands as GCC
inline assembly. This patch tries to make it compatible regarding
LoongArch specific operand modifiers.

GCC supports many modifiers [2], but it seems that only x86 and msp430
are documented [3][4]. I don't know if any other modifiers are being
used except the 'z' in Linux [5].

[1]: https://clang.llvm.org/compatibility.html#inline-asm
[2]: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/loongarch/loongarch.cc#L4884-L4911
[3]: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#x86Operandmodifiers
[4]: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#msp430Operandmodifiers
[5]: https://github.com/torvalds/linux/blob/master/arch/loongarch/include/asm/cmpxchg.h#L17

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

[LoongArch] Replace assertion by error message while lowering RETURNADDR and FRAMEADDR

If `__builtin_frame_address` or `__builtin_return_address` is invoked with
non-zero argument, show an error message instead of a crash.

Reference: https://reviews.llvm.org/rG83b88441ad951fe99c30402930ef3cd661f2fd2b

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

[Clang][LoongArch] Support inline asm constraint 'J'

'J' is defined in GCC [1] but not documented [2] while Linux [3] has
already used it in LoongArch port.

[1]: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/loongarch/constraints.md#L61
[2]: https://gcc.gnu.org/onlinedocs/gccint/Machine-Constraints.html
[3]: https://github.com/torvalds/linux/blob/master/arch/loongarch/include/asm/cmpxchg.h#L19

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

[flang] Catch attempts to do anything with statement functions other than call them

A statement function in Fortran may be called, but it may not be the target
of a procedure pointer or passed as an actual argument.

[NFC][m68k] Add pipeline.ll

[JITLink][i386] Adds absolute and pc relative relocation support for ELF/i386.

This commit adds support for 32 bit absolute and pc relative relocations in
ELF/i386 objects, along with simple regression tests.

Reviewed By: sgraenitz, lhames

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

[flang] Require explicit interface for some dummy procedures

Some of the circumstances that require that a procedure have an
explicit interface at a point of call due to a characteristic of
a dummy argument apply to dummy procedures, too.

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

Make scf.for and affine.for conditionally speculatable

for (I = Start; I < End; I += 1) always terminates so mark
{scf|affine}.for as RecursivelySpeculatable when step is known to be
1.

Reviewed By: chelini

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

[JITLink][aarch64] Remove the unused PairedAddend aarch64 edge kind.

This is a vestige of the original MachO-specific edge set and was never used
as a generic aarch64 edge kind.

[flang][MSVC] Disable test

Disable the test that corresponds to a semantic check that was
disabled to work around an MSVC build problem.

[flang] Enforce C815

A Fortran program may not specify a particular attribute multiple
times for the same entity in a scope.

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

[InstCombine] Allow memcpys from constant memory to readonly nocapture parameters to be elided.

Currently, InstCombine can elide a memcpy from a constant to a local alloca if
that alloca is passed as a nocapture parameter to a *function* that's readnone
or readonly, but it can't forward the memcpy if the *argument* is marked
readonly nocapture, even though readonly guarantees that the callee won't
mutate the pointee through that pointer. This patch adds support for detecting
and handling such situations, which arise relatively frequently in Rust, a
frontend that liberally emits readonly.

A more general version of this optimization would use alias analysis to check
the call's ModRef info for the pointee, but I was concerned about blowing up
compile time, so for now I'm just checking for one of readnone on the function,
readonly on the function, or readonly on the parameter.

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

[ADT] Make mapped_iterator copy assignable

As mentioned in https://discourse.llvm.org/t/rfc-extend-ranges-infrastructure-to-better-match-c-20/65377

Lambda objects are not copy assignable, and therefore neither are
iterator types which hold a lambda.  STL code require iterators be
copy assignable.  Users may not use mapped_iterator with a std::deque
for example: https://godbolt.org/z/4Px7odEEd

This blog post [1] explains the problem and solution.  We define a
wrapper class to store callable objects with two specialization.

1. Specialization for non-function types
    - Use a std::optional as storage for non-function callable.
    - Define operator=() implementation(s) which use
      std::optional::emplace() instead of the assignment operator.
2. Specialization for function types
    - Store as a pointer (even if template argument is a function reference).
    - Default construct pointer to nullptr.

This Callable wrapper class is now default constructible (with invalid
state) and copy/move assignable.

With these new properties available on the callable object,
mapped_iterator can define a default constructor as well.

[1] https://www.fluentcpp.com/2019/04/16/an-alternative-design-to-iterators-and-ranges-using-stdoptional/

Reviewed By: kazu

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

[flang] Correct a predicate around a semantic check

When a dummy argument is a procedure pointer without INTENT(IN),
any actual argument must also be a procedure pointer, whether the
dummy procedure pointer's interface is explicit or not.

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

[SimpleLoopUnswitch] Forget block and loop dispositions.

Also invalidate block and loop dispositions during non-trivial
unswitching.

Fixes #58564.

[flang] Don't resolve component names to components in derived-type definition scope

We implemented 19.3.4p1 literally in name resolution:

  A component name has the scope of its derived-type definition. Outside the type definition,
  it may also appear within a designator of a component of a structure of that type or as a
  component keyword in a structure constructor for that type.

and within the derived-type definition would resolve the "bare"
names of components in specification inquiries and other contexts to
those components, not to any symbols in the enclosing scopes.

It turns out that most Fortran compilers resolve only "bare" names thus
when they are type parameters, and the names of data and procedure components
do not shadow exterior symbols.  Adjust name resolution to follow that
precedent rather than what seems to be clear language in the standard.

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

[flang][NFC] Change wording of an I/O runtime error message

Make a requested change to the wording of a fatal I/O error
message.

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

[llvm-objdump] Set --print-imm-hex by default.

This was previously attempted in 2016 by colinl's D18770, but LLD tests
were missed, which caused the change to be reverted.

Setting --print-imm-hex by default brings llvm-objdump's behavior closer
in line with objdump, and it makes it easier to read addresses and
alignment from the disassembly. It may make non-address immediates
harder to interpret, but it still seems the better default, barring more
context-sensitive base selection logic.

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

[llvm-objdump] Add --no-print-imm-hex to new tests depending on it.

This prepares for an upcoming change to make --print-imm-hex the default
behavior of llvm-objdump. A few newly-added tests were missed the first
time around.

See D136972 for details.

[lld] Fix a warning

This patch fixes:

  lld/MachO/SyntheticSections.cpp: In member function ‘virtual void
  lld::macho::ChainedFixupsSection::writeTo(uint8_t*) const’:

[flang][MSVC] Take 2 on a work-around for bogus MSVC error

Previous attempt to work around a bogus error from MSVC 14 on
code from a recent patch failed, so add an #ifdef and disable
the feature for MSVC builds to get the build bot back up.

[lld] Fix a warning

This patch fixes:

  lld/MachO/OutputSegment.cpp:50:43: warning: enumerated and
  non-enumerated type in conditional expression [-Wextra]

Revert "[ADT] Remove redundaunt typename (NFC)"

This reverts commit 95eaefd0df7564a380f71a6909a5bd6b3ad32ab2.

I accidentally committed a patch to add a redundant typename.

[test][asan] Make the printf-5.c test case actually emit a volatile memcpy.

The current test in printf-5.c appears to try to emit a volatile memcpy for the
format string, but it doesn't because the volatile qualifier is implicitly
casted away. Using a string literal instead preserves the volatile qualifier.

This is a follow-up to D137031 and is a prerequisite for D136822, which elides
memcpys in more instances and would otherwise break this test.

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

[ADT] Remove redundaunt typename (NFC)

[AMDGPU] Fix a warning

This patch fixes:

  llvm/lib/Target/AMDGPU/SIInstrInfo.cpp:7383: warning: enumerated
  mismatch in conditional expression:
  ‘llvm::AMDGPU::UfmtGFX11::UnifiedFormat’ vs
  ‘llvm::AMDGPU::UfmtGFX10::UnifiedFormat’

[Mips] Fix a warning

This patch fixes:

  llvm/lib/Target/Mips/MipsInstrInfo.cpp:71:52: warning: enumerated
  and non-enumerated type in conditional expression [-Wextra]

[flang][MSVC] Work around what seems to be a bogus MSVC error

Recode a recent patch in an attempt to dodge a nonsensical error
from MSVC 14.

[Hexagon] Remove HexagonVectorCombine::simplify

This patch fixes:

  llvm/lib/Target/Hexagon/HexagonVectorCombine.cpp:1554:6: warning:
  ‘llvm::Value*
  {anonymous}::HexagonVectorCombine::simplify(llvm::Value*) const’
  defined but not used [-Wunused-function]

[Analysis] Fix warnings

This patch fixes:

  llvm/utils/unittest/googletest/include/gtest/gtest.h:1526:11: error:
  comparison of integers of different signs: 'const unsigned long' and
  'const int' [-Werror,-Wsign-compare]

ManagedStatic: remove from DebugCounter

[Re-submit after earlier revert due to a test failure. Commit dce78646f07
("clang-tblgen build: avoid duplicate inclusion of libLLVMSupport")
is believe to address the root cause of the test failure.]

Follow the pattern used in MLIR for the cl::opt instances.

v2:
- make DebugCounter::isCountingEnabled public so that the
  DebugCounterOwner doesn't have to be a nested class. This simplifies
  later changes

v3:
- remove the indirection via DebugCounterOwner::instance()

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

[flang] Fix a warning

This patch fixes:

  flang/lib/Evaluate/fold-integer.cpp:613:25: error: lambda capture
  'name' is not used [-Werror,-Wunused-lambda-capture]

[flang][MSVC] Resolve warning message

MSVC emits a warning on some recently patched code; fix it.

[JITLink][AArch64] Remove unused Pointer64Anon edge kind.

Pointer64Anon was lifted out of the MachO backend and into aarch64.h when that
header was created, but Pointer64Anon is really a MachO-specific "normalized"
relocation value, rather than a generic Edge::Kind. Any uses can be safely
replaced with Pointer64.

(Side note: the role of MachOPointer64Anon is to aid MachO relocation parsing:
For MachOPointer64, the target symbol is specified by the r_symbolnum field in
the relocation. For MachOPointer64Anon the address of the anonymous target is
read from the fixup location.)

[flang] Complex constructors are scalar only

The common language extension that allows arbitary expressions
to be used as components in a complex constructor (x,y) -- not both
constant, since that would make it a complex literal constant --
still have to be scalar; it's not an elemental operation like the
CMPLX() intrinsic function is.

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

[flang] Emit warnings when results of folding some integer intrinsics overflow

When the compile-time result value of a reference to an integer-valued intrinsic
function COUNT, ICHAR, IACHAR, INDEX, SCAN, or VERIFY cannot be represented in
the selected result kind, emit a warning.

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

[ValueTracking] Assert known bits sanity in isKnownNonZero

These are the same asserts we have in other query routines; cover this interface too.

[X86] Remove unnecessary MMX PACKSS/PACKUS SchedWriteRes overrides

These overrides should now match the default WriteShuffle schedules

This also fixes a typo where we were missing load latencies for the memory folded variants

[VectorUtils] Add getShuffleDemandedElts helper

We have similar code to translate a demanded elements mask for a shuffle's operands in multiple places - this patch adds a helper function to VectorUtils and updates a number of locations to use it directly.

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

[flang] Stricter scrutiny of MOVE_ALLOC calls

Enforce remaining semantic restrictions on the arguments to MOVE_ALLOC,
namely that the first two arguments must be allocatable (!) and that
if the source is polymorphic, so must the destination be.

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

[clang-tools-extra] Use llvm::find (NFC)

Allow scalable vectors in computeKnownBits

This extends the computeKnownBits analysis to support scalable vectors. The critical detail is in deciding how to represent the demanded elements of a vector whose length is unknown at compile time.

For this patch, I adopt the convention that we track one bit which corresponds to all lanes. That is, that bit is implicitly broadcast to all lanes of the scalable vector resulting in all lanes being demanded. This is the same convention we use in getSplatValue in SelectionDAG.

Note that this convention doesn't actually impact much. Most of the code is agnostic to the interpretation of the demanded elements, and the few cases which actually care need case by case handling anyways. In this patch, I just bail out of those cases.

A prior patch (D128159) proposed using a different convention in SDAG. I don't see any strong reason to prefer one scheme over the other, so I propose we go with this one as it's conceptually the simplest. Getting known and demanded bit optimizations unblocked at all is a significant win.

I've locally implemented this scheme in reasonable large parts of ValueTracking.cpp and SelectionDAG equivalents, and have not hit any blockers. If this is approved, I plan to post a series of patches plumbing this through all the relevant parts.

In the discussion on that patch, a preference was expressed for introducing some form of abstraction around the demanded elements. I'll note that I've played with several variations on that idea locally, and have yet to find anything which results in more readable code. If anyone has concrete ideas in this area, I'm happy to explore in follow up patches. I'd strongly prefer to be making API changes in NFC manner with tests in place.

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

[X86] Fix simd integer ALU and shuffle port allocations

znver1/2 uses pipes0/1/3 for most integer ALU and nearly all integer/float shuffles occur on pipes1/2

More cleanup work to hopefully get shuffle kinds costs testing added to the D103695 script sometime soon

Confirmed with the AMD SoG, Agner + instlatx64

[X86] Ensure 256-bit sqrt + crosslane shuffles are set to 2 uops + half rate

Fixes another mismatch between the D103695 script and the znver1 scheduler model

Confirmed with the AMD SoG, Agner + instlatx64

[InstCombine] refactor the SimplifyUsingDistributiveLaws NFC

Precommit for D136015
Reviewed By: spatel
Differential Revision: https://reviews.llvm.org/D137019

Fix the clang Sphinx build

This should address the issue found in:
https://lab.llvm.org/buildbot/#/builders/92/builds/34906

[clang-format] Adds a formatter for aligning trailing comments over empty lines

This patch addresses https://github.com/llvm/llvm-project/issues/19756

Reviewed By: MyDeveloperDay, HazardyKnusperkeks

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

[test][InstCombine] Add tests for removing memcpy to an alloca that is passed to a readonly nocapture function parameter, in preparation for D136822.

This commit adds tests to Transforms/InstCombine/memcpy-from-global.ll that
test various situations involving memcpy from a constant to an alloca that is
then passed to function parameters with various attributes. The forthcoming
D136822 allows InstCombine to remove these memcpys if they're passed to a
single readonly nocapture parameter.

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

[InstCombine] Avoid deleting volatile memcpys.

InstCombine can replace memcpy to an alloca with a pointer directly to the
source in certain cases. Unfortunately, it also did so for volatile memcpys.
This patch makes it stop doing that.

This was discovered in D136822.

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

[test][InstCombine] Add a test case for volatile memcpy forwarding in InstCombine, which is currently optimized incorrectly.

D136822 demonstrated that we currently delete volatile memcpys in InstCombine,
which we shouldn't do. This commit adds a test for this. A forthcoming commit
will fix it.

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

[clang][Interp] Implement bitXor opcode

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

[clang][Interp] Implement left and right shifts

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

[mlir] Fix a warning

This patch fixes:

  mlir/include/mlir/IR/PatternMatch.h:1209:72: warning: parameter
  ‘values’ set but not used [-Wunused-but-set-parameter]

[clang][Interp] Implement add and sub compound assign operators

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

[ADT] Remove redundant typename (NFC)

[clang-format] Don't crash on malformed preprocessor conditions

Previously the program would crash on this input:

```
#else
#if X
```

The problem was that in `parsePPElse`, `PPBranchLevel` would be
incremented when the first `#else` gets parsed, but `PPLevelBranchCount`
and `PPLevelBranchIndex` would not be updated together.

I found the problem when working on D135740.

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

[flang] Abstract interfaces can't be designated or referenced

Broaden the check for misuse of ABSTRACT procedure interfaces by
doing it in expression analysis rather than name resolution so that
cases like pointer assignment targets and actual arguments are also
diagnosed as errors.

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

[flang] Stricter scrutiny of deferred type parameters (C702)

Semantics checks C702, which disallows deferred type parameters for
any entity that is neither an allocatable nor a pointer, only during
name resolution of type declaration statements.  This check needs to
be broader, since Fortran entities can have their types specified in
other ways.  Rewrite the check and move it to the general declaration
checking pass.

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

[flang] Catch C721 violations in defined interfaces

Fortran's constraint C721 allows an assumed-length CHARACTER
entity to be declared in a very limited set of circumstances that
does not include an explicit external interface definition.

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

[flang] Catch inconsistent function/subroutine usage of procedure pointer components

When a derived type has a procedure pointer component with no interface,
we can't do a lot of checking on its call sites, but we can at least require
that the same procedure pointer component be used consistently as either
a function or as a subroutine, but not both.

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

[flang] Warn about overflow from folding complex ABS()

Emit a warning when the result of folding a call to
ABS() with a complex argument results in an overflow.

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

[flang] Recode a line to dodge a clang warning

Rewrite a correct use of "&" -- conjunction without short-circuiting --
from a recent patch into multiple lines so that clang doesn't warn
about it.

[llvm-objdump] Add --no-print-imm-hex to tests depending on it.

This prepares for an upcoming change to make --print-imm-hex the default
behavior of llvm-objdump. These tests were updated in a semi-automatic
fashion.

See D136972 for details.

[test][AliasAnalysis] Add some baseline tests in preparation for getModRefInfoMask().

This commit adds some tests in preparation for D136659, which allows alias
analysis to treat locally-invariant memory pointed to by readonly noalias
pointers the same as globally-invariant memory in some cases. The existing
behavior for these tests is marked as expected and will be changed when that
diff lands.

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

[test] Remove readonly from some parameters that are written through in tests.

In D136659 I found a few tests that write through readonly parameters:

* Analysis/BasicAA/pr18573.ll: @foo1 writes through %arr.ptr, but declares it
readonly. I removed the readonly annotation.

* CodeGen/ARM/ParallelDSP/aliasing.ll: @restrict writes through the readonly
%arg3, @store_alias_arg3_illegal_1 writes through the readonly %arg3, and
@store_alias_arg3_illegal_2 writes through the readonly %arg3. I removed
readonly from all three. Also, I added some CHECK-LABEL directives to make it
harder for FileCheck output to be mixed up.

* Transforms/LoopVectorize/AArch64/sve-gather-scatter.ll:
@gather_nxv4i32_ind64_stride2 writes through the readonly %a. I removed the
readonly attribute.

* Transforms/LoopVectorize/interleaved-accesses.ll: @load_gap_reverse writes
through the readonly %P1 and %P2. Also, the corresponding C code in the comment
didn't match the test. I removed the readonly attribute from both parameters
and corrected the C code.

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

[flang] Enforce constraint C911

Diagnose attempts to use an non-polymorphic instance of an
abstract derived type.

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

[flang] Speed up folding of LEN_TRIM()

LEN_TRIM's folding is currently based on VERIFY(), and it is kind of
slow for the very large CHARACTER arguments that can show up in artificial
test suites.  Rewrite in terms of single-character accesses.

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

[flang] Improve error recovery for bad/missing construct END statements

When a multi-statement construct should end with a particular END statement
like "END SELECT", and that construct's END statement is missing or
unrecognizable, the error recovery productions should not misinterpret
a program unit END statement that follows and consume it as a misspelled
construct END statement. Doing so leads to cascading errors or a failed parse.

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

[flang] Fix warning from clang 16 on recent patch

Add an explicit empty initializer to a new struct member definition
to silence warnings from clang 16 about missing initializers.

[ORC] Mark late-claimed weak symbols as live in ObjectLinkingLayer.

ObjectLinkingLayer attempts to claim responsibility for weak definitions that
are present in LinkGraphs, but not present in the corresponding
MaterializationResponsibility object. Where such a claim is successful, the
symbol should be marked as live to prevent it from being dead stripped.

(For the curious: Such "late-breaking" definitions are introduced somewhere in
the materialization pipeline after the initial responsibility set is calculated.
The usual source is the complier or assembler. Examples of common late-breaking
definitions include personality pointers, e.g. "DW.ref.__gxx_personality_v0",
and named constant pool entries, e.g. __realXX..XX.)

The failure to mark these symbols live caused few problems in practice because
late-breaking definitions are usually anchored by existing live definitions
within the graph (e.g. DW.ref.__gxx_personality_v0 is transitively referenced by
functions via eh-frame records), and so they usually survived dead-stripping
anyway. This accidental persistence isn't a principled solution though, and it
fails altogether if a late-breaking definition is not otherwise referenced by
the graph, with the result that the now-claimed symbol is stripped triggering a
"Failed to materialize symbols" error in ORC. Marking such symbols live is the
correct solution.

No testcase, as it's difficult to construct a situation where a late-breaking
definition is inserted without being referenced outside the context of new
backend bringup or plugin-specific shenanigans.

See discussion in https://reviews.llvm.org/D133452 and
https://reviews.llvm.org/D136877.

Revert "Handle errors in expansion of response files"

This reverts commit 17eb198de934eced784e16ec15e020a574ba07e1.
Reverted for investigation, because ClangDriverTests failed on some builders.

[flang] Catch and diagnose attempts to misuse NULL()

Some intrinsic functions can handle NULL() as an actual argument; most
can't.  Distinguish the two with a new ArgFlag facility in the intrinsic
procedure table.  Also transform some confusing Optionality codes that
were standing in for flags into ArgFlags.  Last, return false for a NULL()
pointer from the utility IsActuallyConstant(), ensuring that it can
still deal with a nested NULL() for components in structure constructors.

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

[VPlan] Use onlyFirstLaneUsed in sinkScalarOperands.

Replace custom code to check if only the first lane is used by generic
helper `onlyFirstLaneUsed`. This enables VPlan-based sinking in a few
additional cases and was suggested in D133760.

Reviewed By: Ayal

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

[Hexagon] Report changes in HvxIdioms pass

It can produce some dead code, which is harmless in the end, but breaks
expensive checks when unreported. This should be fixed eventually, but
it's a low priority.

[flang] Clarify cases where name resolution of generic shadowing can be overridden

Fortran famously allows a generic interface definition to share a
scope with a procedure or derived type of the same name.  When that
shadowed name is accessed via host or USE association, but is also
defined by an interface in the generic, then name resolution needs
to fix up the representation of the shadowing so that the new interface
definition is seen as the shadowed symbol -- the host or USE associated
name is not material to the situation.  See the new test case for
particular examples.

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

[Hexagon] Break up vectors into HVX-sized chunks in HvxIdioms

This will allow recognizing Q.31 multiplications on vectors that are
multiplies of HVX vectors. At the moment this comes at the expense of
Q.15 multiplications, which now are handled as 32-bit multiplications
with shifts.
In the longer term this will likely be replaced by a different scheme
of "legalizing" vectors, which is necessary for idiom recognition, at
least where using direct HVX instrinsics is desired.

Recommit [AArch64] Optimize memcmp when the result is tested for [in]equality with 0

Fixes 1st issue of https://github.com/llvm/llvm-project/issues/58061
Fixes the crash of https://github.com/llvm/llvm-project/issues/58675

Reviewed By: dmgreen, efriedma
Differential Revision: https://reviews.llvm.org/D136244

[Hexagon] Fix vector concatenation

[InstCombine] fold mul with incremented "shl 1" factor

X * ((1 << Z) + 1) --> (X << Z) + X

https://alive2.llvm.org/ce/z/P-7WK9

It's possible that we could do better with propagating
no-wrap, but this carries over the existing logic and
appears to be correct.

The naming differences on the existing folds are a result
of using getName() to set the final value via Builder.
That makes it easier to transfer no-wrap rather than the
gymnastics required from the raw create instruction APIs.

[InstCombine] create helper function for mul patterns with 1<<X; NFC

There are at least 2 other potential patterns that could go here.

[X86] Remove the WriteDPPSZ schedule pair

There's never been a 512-bit vdpps instruction (and the implementation is so convoluted there probably won't ever be)

[X86] Remove 256-bit scheduler classes

SLM (silvermont) doesn't support any AVX instructions

Handle errors in expansion of response files

Previously an error raised during an expansion of response files (including
configuration files) was ignored and only the fact of its presence was
reported to the user with generic error messages. This made it difficult to
analyze problems. For example, if a configuration file tried to read an
inexistent file, the error message said that 'configuration file cannot
be found', which is wrong and misleading.

This change enhances handling errors in the expansion so that users
could get more informative error messages.

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

[InstCombine] reduce code duplication in visitMul(); NFC

[InstCombine] add tests for mul with shl operand; NFC

[ARC] Regenerate ldst.ll

Reported by the (experimental) arc buildbot after D136042

[mlir] Split parser fuzzer for bytecode & text

Enable fuzzing these independently. Currently still not linking in
dialects beyond Builtin.

[DAG] Enable combineShiftOfShiftedLogic folds after type legalization

This was disabled to prevent regressions, which appear to be just occurring on AMDGPU (at least in our current lit tests), which I've addressed by adding AMDGPUTargetLowering::isDesirableToCommuteWithShift overrides.

Fixes #57872

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

[lit] Deduplicate README and longdescription, and update it

Since long_description is effectively the README that's displayed
on pypi project page, combine it with the existing README file and read
the file in `setup.py`.  This is a common practice among Python
projects, to the point of declarative-style setuptools configurations
providing a shorthand for it.

While at it, update the outdated information about LLVM Bugzilla for use
of GitHub issues.

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

[X86] WriteFShuffle256 shuffles aren't microcoded in the llvm sense

znver1/2 might have poor throughput for crosslane shuffles but they don't consume 100 cycles of resources

I think there was a misunderstanding between the AMD definition of microcoding (more than 2-3 uops) and LLVM (here be dragons - impossible to approximately model the instruction)

This is more yak shaving to come from D103695 - this time working out why codegen involving broadcasts gives such weird numbers