[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

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

znver1 double pumps regular 256-bit shuffles (crosslane shuffles are messier....)

Fixes yet another mismatch between the numbers coming out of the script from D103695 and the znver1 scheduler model

Confirmed with the AMD SoG, Agner + instlatx64

[JITLink][RISCV] Add names for GOT/PLT relocations

It is confusing to see "Unrecognized edge kind" in debugging output
for supported relocations; this was probably an oversight in commit
89f546f6ba which added the support.

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

[LoongArch] Improve the "out of range" error information reported by `adjustFixupValue`

There are three reduplicate error messages for different conditions. I
add meaningful information to make them more informative.

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

[docs] clang.rst: gnu++14 => gnu++17

[gn build] Port 30ea3fcc4c69

[clang-format][NFC] Move BracesRemover tests out of FormatTest.cpp

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

Revert "Revert "[scudo] Fix the calculating of memory group usage""

This reverts commit 69fe7abb393ba7d6ee9c8ff1429316845b5bad37.

Fixed the arguments order while calling batchGroupBase()

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

[clang][NFC] sync comments from declaration of InitializePreprocessor

[libc] Fix the return value of fread and fwrite.

They were previously returning the number of bytes read. They should
instead be returning the number of objects read.

[mlir] Fix the bazel error after c853d69ab9778fece61b0bf63a71609f437a483d

ARM: Fix stack warning test

clang: Improve errors for DiagnosticInfoResourceLimit

Print source location info and demangle the name, compared
to the default behavior.

Several observations:

1. Specially handling this seems to give source locations
without enabling debug info, and also gives columns compared
to the backend diagnostic.

2. We're duplicating diagnostic effort in DiagnosticInfo
and clang. This feels wrong, but clang can demangle and I guess
have better debug info available? Should clang really have any of this
code? For the purposes of this diagnostic, the important piece
is just reading the source location out of the llvm::Function.

3. lld is not duplicating the same effort as clang with LTO, and
just directly printing the DiagnosticInfo as-is. e.g.

  $ clang -fgpu-rdc
lld: error: local memory (480000) exceeds limit (65536) in function '_Z12use_huge_ldsIiEvv'
lld: error: local memory (960000) exceeds limit (65536) in function '_Z12use_huge_ldsIdEvv'

  $ clang -fno-gpu-rdc
backend-resource-limit-diagnostics.hip:8:17: error: local memory (480000) exceeds limit (65536) in 'void use_huge_lds<int>()'
__global__ void use_huge_lds() {
                ^
backend-resource-limit-diagnostics.hip:8:17: error: local memory (960000) exceeds limit (65536) in 'void use_huge_lds<double>()'
2 errors generated when compiling for gfx90a.

4. Backend errors are not observed with -save-temps and -fno-gpu-rdc or -flto,
and the compile incorrectly succeeds.

5. The backend version prints error: <location info>; clang prints <location info>: error:

6. -emit-codegen-only is totally broken for AMDGPU. MC
gets a null target streamer. I do not understand why this
is a thing. This just creates a horrible edge case.
Just work around this by emitting actual code instead of blocking
this patch.

DiagnosticInfo: Report function location for resource limits

We have some odd redundancy where clang specially handles
the stack size case. If clang prints it, the source location is first
followed by "warning". The backend diagnostic, as printed by other tools
puts "warning" first.

llvm-reduce: Fix typo

[Frontend] -MP: remove blank lines

GCC 10 removed blank lines for phony targets during a refactoring.
The blank lines seems unuseful, so let's follow suit.

[Frontend] Fix -MP when main file is <stdin>

rC220726 had a bug: `echo "<cstdlib>" | clang -M -MP -x c++ - 2>/dev/null`
(used by glibc/configure.ac find_cxx_header) omitted a `cstdlib:` line. Instead
of filtering out `<stdin>` in `Dependencies`, retain it (so that the number of
entries does not change whether or not main file is `<stdin>`) and filter the
`PhonyTarget` output.

[mlir][sparse] Cleaning up function names in test

The old "dumpAndRelease" names are no longer valid since the "release" part is handled separately now.

Reviewed By: Peiming

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

[mlir][sparse] run canonicalization pass after DenseOpBufferize.

As pointed out by Matthias: "DenseBufferizationPass should be run right after TensorCopyInsertionPass. (Running it after bufferizing the sparse IR is also OK.) The reason for this is that whether copies are needed for not depends on the structure of the program (SSA use-def chains). In particular, running the canonicalizer in-between is problematic because it could introduce new RaW conflicts"

Reviewed By: aartbik

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

Fix MLIR build after D136931

ld.lld: error: undefined symbol: mlir::extractFromI64ArrayAttr(mlir::Attribute)
>>> referenced by NVVMToLLVMIRTranslation.cpp:142
  (/llvm-project/mlir/lib/Target/LLVMIR/Dialect/NVVM/NVVMToLLVMIRTranslation.cpp:142)
>>> referenced by NVVMToLLVMIRTranslation.cpp:152
  (/llvm-project/mlir/lib/Target/LLVMIR/Dialect/NVVM/NVVMToLLVMIRTranslation.cpp:152)

llvm-reduce: Fix producing invalid reductions with landingpads

It's not valid to simply branch to a landingpad block, so it
needs to be removed.

Also stop trying to scan forward to find a block that can be merged.
The predecessor merge rules are more complex than this. This also
would need to have considered landingpads. Just do the minimum
to delete the block, and let the simplify-cfg reduction handle
the branch chain cleanups.

llvm-reduce: Fix block reduction with unreachable blocks

Previously this would produce many invalid reductions with
"Instruction does not dominate uses" verifier errors.

This fixes issues in cases where the incoming IR
has unreachable blocks, and the resulting reduction
introduced new reachable blocks.

Have basic-blocks skip functions that have unreachable
blocks, Introduce a separate reduction which only
deletes unreachable blocks. Cleanup any newly unreachable
blocks after trimming out the requested deletions.

Includes a variety of meta-reduced tests for llvm-reduce
itself with -abort-on-invalid-reduction that were failing
on different iterations of this patch.

Bugpoint's implementation is much simpler (but currently I don't
understand how it avoids disconnecting interesting blocks from the CFG).

llvm-reduce: Don't turn switches into returns

Re-use one of the existing successors as the new default.
This helps with a future patch to fix handling of unreachable
blocks.

[clang][test] Require x86 target in a couple new tests

Attempt to fix test failures on bots that don't configure x86 target.

clang: Add required target to test

[llvm-tblgen] NFC: Simplify DecoderEmitter.

Currently the DecoderEmitter constructor takes a bunch of string
parameters containing bits of code to interpolate.

However, there's only two ways it can be called. The one used for most
targets which doesn't handle the SoftFail DecoderStatus (not a
problem, because they don't use SoftFail). The other mode, which is
used for ARM/AArch64, does handle SoftFail, but requires an externally
defined helper function in those targets.

This is unnecessary complication; remove the parameters, and unify
onto a single version which does support SoftFail, defining the helper
itself.