[AMDGPU] Iterative scan implementation for atomic optimizer.

This patch provides an alternative implementation to DPP for Scan Computations.

An alternative implementation iterates over all active lanes of Wavefront
using llvm.cttz and performs the following steps:
    1.  Read the value that needs to be atomically incremented using
        llvm.amdgcn.readlane intrinsic
    2.  Accumulate the result.
    3.  Update the scan result using llvm.amdgcn.writelane intrinsic
        if intermediate scan results are needed later in the kernel.

Reviewed By: arsenm, cdevadas

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

[RISCV] Use computeVLMax and getVScale to simplify code. NFC

[GlobalISel] Implement some binary reassociations, G_ADD for now

- (op (op X, C1), C2) -> (op X, (op C1, C2))
- (op (op X, C1), Y) -> (op (op X, Y), C1)

Some code duplication with the G_PTR_ADD reassociations unfortunately but no
easy way to avoid it that I can see.

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

[gn build] Port 60eb1da31555

[Modules] [Sema] Don't try to getAcceptableDecls during the iteration of noload_lookups

I found this during the support of modules for clangd. The reason for
the issue is that the iterator returned by noload_lookups is fast-fail
after the lookup table changes by the design of llvm::DenseMap. And
originally the lookup will try to use getAcceptableDecl to filter the
invisible decls. The key point here is that the function
"getAcceptableDecl" wouldn't stop after it find the specific decl is
invisble. It will continue to visit its redecls to find a visible one.
However, such process involves loading decls from external sources,
which results the invalidation.

Note that the use of "noload_lookups" is rare. It is only used in tools
like FixTypos and CodeCompletions. So it is completely fine for the
tranditional compiler. This is the reason why I can't reproduce it by a
lit test.

[RISCV][NFC] Remove classes/multiclasses for SEW-aware instructions

Instead, we add an argument `isSEWAware` to indicate that the
instruction is SEW-aware. Actually, the only difference is the
name of pseudo instructions.

And we remove postfix `_E` for all classes/multiclasses and remove
argument `sew` since it can be calculated from `log2sew`.

Reviewed By: craig.topper

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

[RISCV][NFC] Replace log2 with !logtwo

`!logtwo` was added in D134068.

Reviewed By: craig.topper

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

[NFC][COFF] Split WinCOFFObjectWriter to WinCOFFWriter

We'd like to support -gsplit-dwarf for Windows COFF. It requires to
write Dwo and NonDwo sections to different output streams.The original
implementation is not designed to do that and there can be only one
MCObjectWriter. This patch split WinCOFFObjectWriter to WinCOFFWriter so
that:
  1. WinCOFFObjectWriter can create multiple WinCOFFWriter.
  2. Each WinCOFFWriter can separately collect sections it is interested.
  3. Each WinCOFFWriter can write to it's own output stream.

Reviewed By: skan

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

[X86][BF16] Split vNbf16 vectors according to vNf16

Fixes #63017

Reviewed By: RKSimon

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

[X86][BF16] Share FP16 vector ABI with BF16

The ABI of BF16 is identical to FP16 rather than i16.

Fixes #62997

Reviewed By: RKSimon

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

[InstrProf][compiler-rt] Fix counter section alignment issue

I recently discovered that `.profraw` headers are expected to be 8 byte
aligned.
https://github.com/llvm/llvm-project/blob/643ba926c1f618401c86dc37e659df795db2e1a0/llvm/lib/ProfileData/InstrProfReader.cpp#L503-L506

When function entry coverage mode is used, function counters are single
bytes, so it is likely that the size of the counters section is not 8
byte aligned. We can add padding after the counters section to guarantee
this.

Reviewed By: kyulee, gulfem

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

[WebAssembly] Error out on invalid personality functions

Without explicitly checking and erroring out, an invalid personality
function, which is not `__gxx_wasm_personality_v0`, caused
a segmentation fault down the line because `WasmEHFuncInfo` was not
created. This explicitly checks the validity of personality functions in
functions with EH pads and errors out explicitly with a helpful error
message. This also adds some more assertions to ensure `WasmEHFuncInfo`
is correctly created and non-null.

Invalid personality functions wouldn't be generated by our Clang, but
can be present in handwritten ll files, and more often, in files
transformed by passes like `metarenamer`, which is often used with
`bugpoint` to simplify names in `bugpoint`-reduced files.

Reviewed By: dschuff

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

[WebAssembly] Undef invalid DBG_VALUEs after RegColoring

After register coalescing, some `DBG_VALUE`s can have incorrect info.
For example, if a `DBG_VALUE` has a register operand `%0`, but it
resides in a live range of `%1`, it has incorrect info after `%0` and
`%1` are coalesced. See the comments for more details.

This does not have meaningful changes on our variable debug info
coverage or compilation time, which is good news.

Reviewed By: dschuff

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

[libc][NFC] fix constants not marked constexpr

The constants in the ryu constant tables were not marked constexpr,
only static const. This caused problems when compiling with GCC.

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

[libc][NFC] land long double table for printf

The Mega Table that printf uses for long doubles with some flags is too
large for the linters, and so has been split out from the main patch.
The main patch: https://reviews.llvm.org/D150399

Reviewed By: sivachandra

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

[C API] Add getters and setters for NUW, NSW, and Exact

This partially addresses Bug 42692; see discussion there.

Adds C API getters and setters for the NUW, NSW, and Exact flags on various
instructions.

Patch by Craig Disselkoen. Thanks!

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

Revert "[Sanitizers][Darwin] In DlAddrSymbolizer, return only the module file name instead of the comlpete module path during symbolication."

The commit broke asan_symbolize.py script on Darwin which depended on
using the complete module path to symolize crash traces offline.

This reverts commit f6ea869f7c043c70722b8db6be94d9ad4cc9eb92.

rdar://110487521

[libc] Disable uint test on NVPTX GPUs

This test started failing on Nvidia, we need to disable it to keep the
bot green until we can investigate the root cause.

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

[lldb][NFCI] Remove use of ConstString from OptionValueProperties

In the interest of keeping the ConstString StringPool small, this patch
aims to remove the use of ConstString from OptionValueProperties.

We can maintain quick lookups by using an llvm::StringMap to find the
correct index by name.

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

[lldb][NFCI] Refactor TypeSystemClang::GetBasicTypeEnumeration

`TypeSystemClang::GetBasicTypeEnumeration(ConstString)` builds up a
giant `UniqueCStringMap<lldb::BasicType>` which is effectively a vector whose elements
are (ConstString, lldb::BasicType). Once sorted, we get to have fairly
quick lookups (O(log n) on average). This is fine, but we can do better
on average with an llvm::StringMap.

This also allows us to simplify the initialization code for the lookup,
no more `once_flag`!

Additionally, I removed unused declarations of related functions from
CompilerType and TypeSystemClang

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

[lldb][NFCI] Remove use of ConstString from OptionValueLanguage

ConstString is simply not needed here.

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

[BOLT] stale profile matching [part 2 out of 2]

This is a first "serious" version of stale profile matching in BOLT. This diff
extends the hash computation for basic blocks so that we can apply a fuzzy
hash-based matching. The idea is to compute several "versions" of a hash value
for a basic block. A loose version of a hash (computed by ignoring instruction
operands) allows to match blocks in functions whose content has been changed,
while stricter hash values (considering instruction opcodes with operands and
even based on hashes of block's successors/predecessors) allow to resolve
collisions. In order to save space and build time, individual hash components
are blended into a single uint64_t.
There are likely numerous ways of improving hash computation but already this
simple variant provides significant perf benefits.

**Perf testing** on the clang binary: collecting data on clang-10 and using it
to optimize clang-11 (with ~1 year of commits in between). Next, we compare
- //stale_clang// (clang-11 optimized with profile collected on clang-10 with **infer-stale-profile=0**)
- //opt_clang// (clang-11 optimized with profile collected on clang-11)
- //infer_clang// (clang-11 optimized with profile collected on clang-10 with **infer-stale-profile=1**)

`LTO-only` mode:
//stale_clang// vs //opt_clang//: task-clock [delta(%): 9.4252 ± 1.6582, p-value: 0.000002]
(That is, there is a ~9.5% perf regression)
//infer_clang// vs //opt_clang//: task-clock [delta(%): 2.1834 ± 1.8158, p-value: 0.040702]
(That is, the regression is reduced to ~2%)
Related BOLT logs:
```
BOLT-INFO: identified 2114 (18.61%) stale functions responsible for 30.96% samples
BOLT-INFO: inferred profile for 2101 (18.52% of all profiled) functions responsible for 30.95% samples
```

`LTO+AutoFDO` mode:
//stale_clang// vs //opt_clang//: task-clock [delta(%): 19.1293 ± 1.4131, p-value: 0.000002]
//infer_clang// vs //opt_clang//: task-clock [delta(%): 7.4364 ± 1.3343, p-value: 0.000002]
Related BOLT logs:
```
BOLT-INFO: identified 5452 (50.27%) stale functions responsible for 85.34% samples
BOLT-INFO: inferred profile for 5442 (50.23% of all profiled) functions responsible for 85.33% samples
```

Reviewed By: Amir

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

Revert "Improve WebAssembly vector bitmask, mask reduction, and extending"

This reverts commit 8392bf6000ad039bd0e55383d40a05ddf7b4af13.

The commit missed some edge cases that led to crashes. Reverting to resolve
downstream breakage while a fix is pending.

[libc] disable printf Lf tests for float128 plats

The results for the %Lf tests were calculated on 80 bit long double
systems, meaning the results are not necessarily accurate for float128
systems. In future these will be fixed, but for the moment I'm just
turning them off.

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

[libc] add options to printf decimal floats

This patch adds three options for printf decimal long doubles, and these
can also apply to doubles.

1. Use a giant table which is fast and accurate, but takes up ~5MB).
2. Use dyadic floats for approximations, which only gives ~50 digits of
   accuracy but is very fast.
3. Use large integers for approximations, which is accurate but very
   slow.

Reviewed By: sivachandra, lntue

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

[Clang] Add check to Sema::AddAlignedAttr to verify active bits is not out of range

If we provide too large a value for the alignment attribute
APInt::getZExtValue() will assert. This PR adjusts existing check to catch
this case and provide a diagnostic.

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

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

AMDGPU: Fix regressions in integer mad matching

Undo the canonicalize done in
0cfc6510323fbb5a56a5de23cbc65f7cc30fd34c. Restores some regressed
matching of integer mad. The selection patterns fo the actual mads
don't seem to be properly commuting, so some of the commuted cases are
still missed.

Fixes: SWDEV-363009

[AppleAccelTable][NFC] Improve code readability

This commit does a few minor NFC cleanups:

* A variable was called "Atom", probably trying to claim it was an AtomType.
This was incorrect, it is actually a FormValue.

* LLVM provides a `zip_equal` to express the intent of asserting ranges with the
same size. We change the lookup method to use that.

* The use of tuples made the code slightly difficult to follow, as such we
unpack the tuple with structure binding to improve readability.

Depends on D152157

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

[lldb] Unconditionally increment depth when printing children

The `target.max-children-depth` setting and `--depth` flag would be
ignored if treating pointer as arrays, fix that by always incrementing
the current depth when printing a new child.

rdar://109855463

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

[NVPTX] Allow using v4i32 for memcpy lowering.

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

[llvm-lib] Pass the right value of MingwDef to parseCOFFModuleDefinition

In llvm-lib cases, the MinGW specific behaviours shouldn't be
enabled.

Not adding any tests to check the corner case behaviours, as this
simply was a mistake when this codepath was added in
395ec4458fb7fc700551f7017c0a395d68c55873 / D144765.

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

[llvm-dlltool] Ignore the --temp-prefix option

llvm-dlltool tolerates unknown options as long as they are plain
flags, but if given the parameter value as a separate argument,
e.g. "--temp-prefix foo", it fails to ignore it.

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

[llvm-dlltool] Clarify parameters, simplify ArgList usage. NFC.

Add comments about unclear bool arguments to functions, switch to
hasArg instead of getLastArg for cases where we don't need to check
the argument's value.

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

[COFF] Remove misleading and unclear comments. NFC.

It is not planned that GNU binutils would change this aspect of
its behaviour wrt how symbol decoration is done.

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

[ExprConstant] fix ICE from Evaluate on _Atomic structs

Fixes two crashes reported by @efriedma and @ahatanak, as per
@ahatanak's analysis.

Link: https://reviews.llvm.org/D151587#4397446
Link: https://reviews.llvm.org/D151587#4399684
Reviewed By: ahatanak, aaron.ballman

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

HIP: Directly call copysign builtins

[LV] Add tests for reasoning about SCEV predicates.

Add extra tests with cases where SCEV predicates can be proven to always
be false. The test in pointer-induction.ll has been adjusted to avoid
the induction always to wrap.

HIP: Directly call isnan builtin

[mlir][transform] Add support for expressing scalable vector sizes

This patch enables specifying scalable vector sizes when using the
Transform dialect to drive vectorisation, e.g.:
```
transform.structured.masked_vectorize %0 vector_sizes [8, 16, [4]]
```
This is implemented by extending the MaskedVectorizeOp with a dedicated
attribute for "scalability" and by overloading `parseDynamicIndexList`
so that MaskedVectorizeOp can continue using the auto-generated parser
and printer.

At the moment, only the trailing vec size can be scalable. The following
is not yet supported:
```
transform.structured.masked_vectorize %0 vector_sizes [8, [16], [4]]
```

As the vectoriser does not support scalable vectorisation just yet, a
warning is issues when scalable vector sizes are used. You can also use
the debug output, `--debug-only=linalg-vectorization`, to check whether
scalable vectorisation has been switched on.

This change is a part of a larger effort to enable scalable
vectorisation in Linalg. See this RFC for more context:
  * https://discourse.llvm.org/t/rfc-scalable-vectorisation-in-linalg/
Similar patch for tiling: https://reviews.llvm.org/D150944

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

[MemProf] Remove stale comment (NFC)

We already do the simplification described in the FIXME comment.

HIP: Directly call isinf builtins

HIP: Directly call signbit builtins

[lldb][NFCI] DecodedThread::TraceItemStorage::error should own its own data

The way it works now, it stores a `const char *` that it does not
explicitly own. It's owned by the ConstString StringPool. This is purely
to manage its lifetime, we don't really benefit from deduplication (nor
should we try to, they are errors). We also don't really benefit from
quick comparisons.

This may make the size of TraceItemStorage larger, but you have to pay
the cost of owning the data somewhere. The ConstString StringPool is an
attractive choice but ultimately a poor one.

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

[OpenMP] Fix --libomptarget-nvptx-bc-path in tests

After D151324, which landed as 349c0aacb380, many libomptarget non-LTO
nvptx64 tests fail with errors like:

```
clang: error: bitcode library '/tmp/llvm-project/build/runtimes/runtimes-bins/openmp/libomptarget/libomptarget-nvptx-sm_70.bc' does not exist
```

This patch updates the bc path.

Reviewed By: jhuber6

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

[mlir][SliceAnalysis] Add an options object to forward and backward slice.

Add an options object to allow control of the slice computation (for
both forward and backward slice). This makes the ABI stable, and also
allows avoiding an assert that makes the slice analysis unusable for
operations with multiple blocks.

Reviewed By: hanchung, nicolasvasilache

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

[AppleAccelTable] Keep track of the size of each hash data entry

In a future patch, it will be desirable to skip over all hash data entries for a
particular string. In order to do so, we must know how many bytes each of those
entries have.

In its full specification, Apple tables allow for variable length entries, which
would make the above impossible without reading the data of each entry. However,
this is largely unsupported today (as a FIXME in the code indicates, there is a
bug with hash collisions exactly because we don't know how to skip over data),
and the documentation[1] states that:

> For the current implementations of the “.apple_names” (all functions +
> globals), the “.apple_types” (names of all types that are defined), and the
> “.apple_namespaces” (all namespaces), we currently set the Atom array to be:
> [...]
> This defines the contents to be the DIE offset (eAtomTypeDIEOffset) that is
> encoded as a 32 bit value (DW_FORM_data4).

In other words, we only produce fixed sized entries.

A few tests containing invalid dwarf had to be updated, as the error is now
detected earlier (when the accelerator table is being parsed, instead of inside
the explicit call to "verify").

[1]: https://llvm.org/docs/SourceLevelDebugging.html#fixed-lookup

Depends on D152156

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

[DebugInfo] Add error-handling to DWARFAbbreviationDeclarationSet

This commit aims to improve error handling in the
DWARFAbbreviationDeclarationSet class. Specifically, we change the return type
of DWARFAbbreviationDeclarationSet::extract to an llvm::Error. In doing
so, we propagate the error from DWARFAbbreviationDeclaration::extract
another layer upward.

I have built on the previous unittest for DWARFDebugAbbrev that I
wrote a few days prior.
Namely, I am verifying that the following should give an error:
- An invalid tag following a non-null code
- An invalid attribute with a valid form
- A valid attribute with an invalid form
- An incorrectly terminated DWARFAbbreviationDeclaration

Additionally, I uncovered some invalid DWARF in an unrelated dsymutil
test. Namely the last Abbreviation Decl was missing a code.
This test has been updated accordingly. However, this commit does
not fix the underlying issue: llvm-dwarfdump does not correctly
verify the debug abbreviation section to catch these kinds of
mistakes. I have updated DWARFVerifier to not dereference a
pointer without first checking it and left a FIXME for future
contributors.

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

[RDF] Add RegisterAggr::refs to return iterator range, NFC

[RDF] Create individual phi for each indivisible register

This isn't quite using register units, but it's getting close. The phi
generation is driven by register units, but each phi still contains a
reference to a register, potentially with a mask that amounts to a unit.
In cases of explicit register aliasing this may still create phis with
references that are aliased, whereas separate phis would ideally contain
disjoint references (this is all within a single basic block).

Previously phis used maximal registers, now they use minimal. This is a
step towards both, using register units directly, and a simpler liveness
calculation algorithm. The idea is that a phi cannot reach a reference
to anything smaller than the phi itself represents. Before there could
be a phi for R1_R0, now there will be two for this case (assuming R0 and
R1 have one unit each).

[RDF] Use RegisterAggr instead of RegisterSet in few places

This shouldn't change any functionality.

[RDF] Clang-format the sources, NFC

[Clang][RISCV] Adjust naming from `DeclareRISCVVectorBuiltins` to `DeclareRISCVSiFiveVectorBuiltins`. NFC

The variable indicates if RISC-V Sifive vector builtin functions
are enabled or not. The adjusted naming help clarifies this.

cc: @4vtomat

Increase memory of BOLT runtime instrumentation bump allocator used for writing resulting profile

The BOLT instrumentation runtime uses a bump allocator that has a fixed amount of maximum memory. In some cases, this memory limit is not large enough (https://github.com/llvm/llvm-project/issues/59174). We are hitting this limit when instrumenting the Rust compiler with BOLT.

This change increases the memory of the bump allocator used for writing the resulting BOLT profile.

Reviewed By: rafauler

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

HIP: Directly call fmin/fmax builtins

[AIX] Update CMake linker flags to use large glink code

Building clang/llvm as a debug build results in TOC overflow even when
using large code model on AIX. This review updates the
llvm/cmake/modules/HandleLLVMOptions.cmake file to use large glink code
in addition to building as a large code model.

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

[lldb][NFC]Update debug (eh-frame) tests to work with new dwarwin MC changes

Details:

D144999 potentially changes the debug format (from compact-unwind to dwarf).
Updated this test to no longer prefer debug-frame over eh-frame to be compatible with the new behaviour

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

[gn build] Port 4d13896d8a2e

[GlobalIsel][X86] Legalize G_SELECT

with bug fixes

Reviewed By: arsenm

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

Reland "[FuncSpec] Improve the accuracy of the cost model"

Instead of blindly traversing the use-def chain of constant arguments,
compute known constants along the way. Stop as soon as a user cannot
be replaced by a constant. Keep it light-weight by handling some basic
instruction types.

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

Reland "[FuncSpec] Replace LoopInfo with BlockFrequencyInfo"

Using AvgLoopIters on any loop is too imprecise making the cost model
favor users inside loop nests regardless of the actual tripcount.

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

[1/11][Clang][Type] Expand BuiltinTypeBits from 8 to 9 bits

This patch-set aims to expand all variants of the RVV segment
load/store intrinsics. The first commit expands the limitation of
builtin types from 256 to 512. The following patches expands the
full variants one-by-one.

The next patch introduces a number of new RVV tuple types and lets the
total of builtin types exceed the current limit (256). This patch
attempts to increase the bits used so we can continue to expand new
builtin types.

Reviewed By: erichkeane

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

[Clang][Type] Add static assertion to guard future expansion for BuiltinType numbering

Recent expansion D152070 exceeds the limit and I had a hard time
triaging the bug because the overflow just creates unexpected
behaviors within the compiler.

This patch adds a static assertion to keep an eye for overflows when we
expand more types in the future.

Reviewed By: aaron.ballman

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

[RISCV] Update documentation for -mvscale-min/max options to mention RISC-V. NFC

[RISCV] Support LMUL!=1 for __attribute__((riscv_rvv_vector_bits(N)))

The first patch supported only LMUL=1 types. This patch supports
LMUL!=1.

LMUL is length multiplier that allows multiple vector registers to
be treated as one large register or a fraction of a single vector
register. Supported values for LMUL are 1/8, 1/4, 1/2, 1, 2, 4, and 8.

An LMUL=2 type will be twice as large as an LMUL=1 type. An LMUL=1/2
type will be half the size as an LMUL=1 type.

Type name with "m2" is LMUL=2, "m4" is LMUL=4.
Type name with "mf2" is LMUL=1/2, "mf4" is LMUL=1/4.

For the LMUL!=1 types the user will need to scale __riscv_v_fixed_vlen
by the LMUL before passing to the attribute.

Reviewed By: aaron.ballman

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

[lldb][test] LogTest: Fix stack overflow

The expected function name requires 18 bytes of storage.

Caught by the public ASAN buildbot

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

[Driver] Make -G TargetSpecific

so that we report `unsupported option '-G' for target ...` on
unsupported targets (most targets).
This error is tested by one target in aix-err-options.c.

Follow-up to D89897 and D90063.

[flang][hlfir] Propagate non-default lbounds from the mutable box.

The issue affected type select tests, such that inside the type guard
block the associated variable was using default lbounds instead of
inheriting it from the original variable.

The bridge's `genExprBox` ended up creating BoxValue from a MutableBoxValue
without setting non-default lbounds. So the hlfir.declare generated
for the associated name inside the type guard block was also using
the default lbounds. The fix is to read the value of the mutable box
and propagate the lbounds to the new BoxValue.

The fix might affect more than just select type cases.

Reviewed By: tblah

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

[Clang] Remove -no-opaque-pointers cc1 flag

Migration of clang tests to opaque pointers is finished, so remove
the -no-opaque-pointers flag.

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

[RISCV] Add test cases to show that rvv_vector_bits attribute is not accepted for vbool or LMUL!=1 RVV types. NFC

The error message isn't great, but it's temporary until we support these.

Reviewed By: aaron.ballman

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

[RISCV] Fix crash in lowerVECTOR_INTERLEAVE when VecVT is an LMUL=8 type.

If VecVT is an LMUL=8 VT, we can't concatenate the vectors as that
would create an illegal type. Instead we need to split the vectors
and emit two VECTOR_INTERLEAVE operations that can each be lowered.

Reviewed By: fakepaper56

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

[RISCV] Fix crash in lowerVECTOR_DEINTERLEAVE when VecVT is an LMUL=8 type.

If VecVT is an LMUL=8 VT, we can't concatenate the vectors as that
would create an illegal type. Instead we need to split the vectors
and emit two VECTOR_DEINTERLEAVE operations that can each be lowered.

Reviewed By: luke, rogfer01

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

[Clang] Remove some explicit -opaque-pointers options in tests (NFC)

This is the default, so don't specify it explicitly, in preparation
for removing the option.

[GlobalISel] Check if ShiftAmt is greater then size of operand

matchCombineShlOfExtend did not check if the size of new shift would be
wider then a size of operand. Current condition did not work if the value
being shifted was zero. Updated to support vector splat.

Patch by: Acim Maravic

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

Revert "[DebugMetadata] Simplify handling subprogram's retainedNodes field. NFCI (1/7)"

This reverts commit 4418434c6de7a861e241ba2448ea4a12080cf08f.

Reverted because it breaks tests of OCaml bindings.

[Hexagon] Make RDF copy propagation a bit more aggressive

Update the testcase to actually test for RDF's output.

[RISCV] Add VPatBinaryVL_V to VPatBinaryFPWVL_VV_VF_WV_WF like VPatBinaryWVL_VV_VX_WV_WX.

This should hopefully fix a regression from D151969.

[Flang] Replace intrinsic function type generators with single generic function type generator

In a future patch we plan on introducing a large set of Power-PC specific intrinsics. During our prototyping we found that the number of function type generators we were defining, plus those already defined, were reaching an unreasonable number. This patch introduces a generic function type generator function that can be used for almost all cases. The generator supports creating function types with up to 4 arguments and with arguments/return type of types: void, integer, real, and comlex. The intention is for a future patch, which introduces a set of PowerPC-specific vector intrinsics, to also introduce support in the generator for: integer vector, unsigned vector, and real vector types.

Reviewed By: luporl

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

[AppleAccelTable][NFC] Make FormParams member of AppleAccelTable

These are used throughout the class and are recreated every time they are used.
To prevent the risk of it being created incorrectly in different places, we
create it once and in the earliest moment possible: when the table is extracted.

Depends on D151989

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

change checking for auto-init metadata to use `equalsStr` instead of casing MDOperand nodes.

Since `MD_annotation` metadata now supports having mutliple strings in the annotation node. casing Operand to string directly will cause a crash. When checking if `MDOperand` equals str you can use `equalsStr` method.

Reviewed By: serge-sans-paille

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

[StaticAnalyzer] Fix false negative on NilArgChecker when creating literal object

Fix false negative on NilArgChecker when creating literal object, such
as @[nullableObject].

Patch By tripleCC!

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

[x86][MC] Fix movdir64b addressing

This patch is to fix the [[ https://github.com/llvm/llvm-project/issues/63045 | issue 63045]].

Look at the following code:
```
int main(int argc, char *argv[]) {
    int arr[1000];
    __asm movdir64b rax, ZMMWORD PTR [arr]
    return 0;
}
```
Compiling this code using `clang -O0 -fasm-blocks bug.c` gives the a linker error.

The problem seems to be in the generated assembly. Following is the out put of `clang -S -O0 -fasm-blocks bug.c`:
```
movq %rsi, -16(%rbp)
#APP

movdir64b arr, %rax

#NO_APP
xorl %eax, %eax
```
The symbol `arr` should be replaced with some address like `-4(%rbp)`.

This makes me believe that issue is not in the linker, but with the ASM parser.

This issue originates with patch [D145893](https://reviews.llvm.org/D145893). And that's why reverting it fixes the issue. More specifically, the function [isMem512_GR64()](https://github.com/llvm/llvm-project/blob/ff471dcf7669b1ad7903a44d0773bef4eb175eb9/llvm/lib/Target/X86/AsmParser/X86Operand.h#L404) within the [llvm/lib/Target/X86/AsmParser/X86Operand.h](https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/AsmParser/X86Operand.h) file.

Reviewed By: skan

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

[Clang] Convert some tests to opaque pointers (NFC)

These tests all require some adjustments to make sure that struct
types still get generated, mostly done by stripping pointer
indirections.

Some of this may no longer test the situation it was originally
intended for, e.g. the issue from pr18962 just doesn't really
exist anymore with opaque pointers, as we no longer generate
recursive types.

[mlir][spirv] Add a canonicalization pattern for UModOp

Add a transformation for a pattern like

%6 = "spirv.Constant"() <{value = 32 : i32}> : () -> i32
%7 = "spirv.UMod"(%5, %6) : (i32, i32) -> i32
%8 = "spirv.Constant"() <{value = 4 : i32}> : () -> i32
%9 = "spirv.UMod"(%7, %8) : (i32, i32) -> i32

to transform to

%6 = "spirv.Constant"() <{value = 32 : i32}> : () -> i32
%7 = "spirv.UMod"(%5, %6) : (i32, i32) -> i32
%8 = "spirv.Constant"() <{value = 4 : i32}> : () -> i32
%9= "spirv.UMod"(%5, %8) : (i32, i32) -> i32

Patch By: nbpatel
Reviewed By: antiagainst, kuhar

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

[AppleAccelTable][NFC] Refactor equal_range code

The current implementation of AppleAcceleratorTable::equal_range has a couple of
drawbacks:

1. Assumptions about how the hash table is structured are hard-coded throughout
the code. Unless you are familiar with the data layout of the table, it becomes
tricky to follow the code.
2. We currently load strings from the string table even for hashes that don't
match our current search hash. This is wasteful.
3. There is no error checking in most DataExtractor calls that can fail.

This patch cleans up (1) by making helper methods that hide the details of the
data layout from the algorithms relying on them. This should also help us in
future patches, where we want to expand the interface to allow iterating over
_all_ entries in the table, and potentially clean up the existing Iterator
class.

The changes above also fix (2), as the problem "just vanishes" when you have a
function called "idxOfHashInBucket(SearchHash)".

The changes above also fix (3), as having individual functions allow us to
expose the points in which reading data can fail. This is particularly important
as we would like to share this implementation with LLDB, which requires robust
error handling.

The changes above are also a step towards addressing a comment left by the
original author:
```
  /// TODO: Generalize the rest of the AppleAcceleratorTable interface and move it
  /// to this class.
```
I suspect a lot of these helper functions created also apply to DWARF 5's
accelerator table, so they could be moved to the base class.

The changes above also expose a bug in this implementation: the previous
algorithm looks at _one_ string inside the bucket, but never bothers checking
for collisions. When the main search loop is written as it is with this patch,
the problem becomes evident. We do not fix the issue in this patch, as it is
intended to be NFC.

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

[mlir][Linalg][Transform] Fail gracefully instead of asserting

[ThinLTO] Ignore callee edge to global variable

Since the symbols in the ThinLTO summary are indexed by GUID we can end
up in corner cases where a callee edge in the combined index goes to a
summary for a global variable. This could happen in the case of hash
collisions, and in the case of SamplePGO profiles could potentially happen
due to code changes (since we synthesize call edges to GUIDs that were
inlined callees in the profiled code).

Handle this by simply ignoring any non-FunctionSummary callees.

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

[Clang] Convert some tests to opaque pointers (NFC)

[mlir][irdl] NFC: Ensure ops ends with `Op` suffix

IRDL operations were inconsistent in their naming. They now
all end with the `Op` suffix.

Reviewed By: rriddle, jpienaar

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

[MLIR][GPU] Add 16-bit version of cudaMemset in cudaRuntimeWrappers

Add 16-bit version of cudaMemset in cudaRuntimeWrappers and update the GPU to LLVM lowering.

Reviewed By: bondhugula

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

X86: Add more is.fpclass lowering tests

AMDGPU: Don't run AMDGPUAttributor with -O0

[SimpleLoopUnswitch] Verify LoopInfo after turning guards to branches

SplitBlockAndInsertIfThen doesn't correctly update LoopInfo when called
with Unreachable=true, which is the case when we turn guards to branches
in SimpleLoopUnswitch.

This adds LoopInfo verification before returning from turnGuardIntoBranch.

AMDGPU: Merge dag and gisel tests for non-entry LDS handling

AMDGPU: Fix errors in test from using non-gfx calling convention

[BOLT] Handle recursive calls as inter-branches in DataAggregator

Align yaml and fdata profiles by applying the same treatment to recursive
calls (direct, indirect, tail). fdata profile increments entry count when
handling recursive calls. Make perf/pre-aggregated perf reader (DataAggregator)
do the same.

Test Plan:
In pre-aggregated-perf.test, add a dummy pre-aggregated branch entry between
an indirect call in `frame_dummy` function and its entry point.
Check that YAML profile gets incremented entry count for this function.

End-to-end test: https://github.com/rafaelauler/bolt-tests/pull/24

Reviewed By: #bolt, maksfb

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

[LV] Extend test coverage for loops with accesses with clamped indexes.

Extend test coverage ahead of upcoming patches.

[memprof] Fix rawprofile test on 32-bit architectures

The first argument of StackTrace constructor is a pointer to uptr. Match
the type accordingly.

This fixes builds on 32-bit architectures.

[sanitizer_common] Move UNDEFINED attribute outside _MSC_VER guard

The __has_attribute check is sufficient, and if clang-cl is used, the
attribute will be available as well.

[LV] Remove UB caused by undef from pr37248.ll (NFC).

Also generate full check lines.

[mlir][irdl] Add `irdl.c_pred`

`irdl.c_pred` is an attribute constraint defined by a C++ predicate.
Contrary to the other constraints, this operation cannot be used in
dialects that are registered at runtime. Its principal use is to
share dialect definitions that are defined in C++ or ODS.

Reviewed By: Mogball

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