[gn build] Port 1188faa7ab4b

[trace][intelpt] Support system-wide tracing [6] - Break IntelPTCollector into smaller files and minor refactor

IntelPTCollector is very big and has 3 classes in it. It's actually cleaner if each one has its own file. This also gives more visibility to the developer about the different kinds of "tracers" that we have.

Besides that, I'm now restricting the creation of the BinaryData chunks to GetState() instead of having it in different places, which is not very clean, because the gdb-remote protocol should be as restricted as possible.

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

[trace][intelpt] Support system-wide tracing [5] - Disable/enable per-core tracing based on the process state

When tracing on per-core mode, we are tracing all processes, which means
that after hitting a breakpoint, our process will stop running (thus
producing no more tracing data) but other processes will continue
writing to our trace buffers. This causes a big data loss for our trace.
As a way to remediate this, I'm adding some logic to pause and unpause
tracing based on the target's state. The earlier we do it the better,
however, I'm not adding the trigger at the earliest possible point for
simplicity of this diff. Later we can improve that part.

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

[trace][intelpt] Support system-wide tracing [4] - Support per core tracing on lldb-server

This diffs implements per-core tracing on lldb-server. It also includes tests that ensure that tracing can be initiated from the client and that the jLLDBGetState ppacket returns the list of trace buffers per core.

This doesn't include any decoder changes.

Finally, this makes some little changes here and there improving the existing code.

A specific piece of code that can't reliably be tested is when tracing
per core fails due to permissions. In this case we add a
troubleshooting message and this is the manual test:

```
/proc/sys/kernel/perf_event_paranoid set to 1

(lldb) process trace start --per-core-tracing                                         error: perf event syscall failed: Permission denied
 You might need that /proc/sys/kernel/perf_event_paranoid has a value of 0 or -1.
``

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

[gn build] Port 6aabf60f2fb7

[AMDGPU] Add llvm.amdgcn.global.load.lds intrinsic

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

Revert "Reland "[clangd] Indexing of standard library""

This reverts commit ccdb56ac10eef3048135169a67d239328c2b1de6.

Still seeing windows failures on GN bots: http://45.33.8.238/win/58316/step_9.txt

Unfortunately I can't debug these at all - it's a bare unsymbolized
stacktrace, and I can't reproduce the failure.

[AMDGPU] Enable FLAT LDS DMA on gfx9/10 before gfx940

We always had global and scratch loads to LDS in the gfx9,
but did not handle it. These were available via the 'lds'
encoding bit. In gfx940 this bit was reused as 'svs' which
resulted in new '_lds' opcodes effectively pushing this
bit into the opcode, but functionally it is the same. These
instructions are also available on gfx10.

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

[gn build] Port ccdb56ac10ee

[RISCV] Minor reorganization of VSETVLIInfo::operator== for readability [NFC]

Reland "[clangd] Indexing of standard library"

This reverts commit 76ddbb1ca747366417be64fdf79218df099a5973.

[clang][dataflow] Weaken guard to only check for storage location

Weaken the guard for whether a sub-expression has been evaluated to
only check for the storage location, instead of checking for the
value. It should be sufficient to check for the storage location, as
we don't necessarily guarantee that a value will be set for the
location (although this is currently true right now).

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

[RISCV] Canonicalize AVL=setvli to AVL=Imm or AVL=VLMAX

This patch adds a transform to the local prepass in InsertVSETVLI which canonicalizes an AVL of a register from another vsetvli into immediate or VLMAX when VTYPE is the same. In this patch, I chose to be conservative and avoid arbitrary vreg forwarding due to profitability concerns about possibility overlapping live ranges.

This has the effect of eliminating vsetvli instructions in loops which are walking either VLMAX or a constant number of lanes per iteration.

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

[libc] add sprintf

This adds the sprintf entrypoint, as well as unit tests. Currently
sprintf only supports %%, %s, and %c, but the other conversions are on
the way.

Reviewed By: sivachandra, lntue

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

[InstCombine] fold more shuffles with FP<->Int cast operands

shuffle (cast X), (cast Y), Mask --> cast (shuffle X, Y, Mask)

This extends the transform added with 0353c2c996c5.

If the casts are to a larger element type, the transform
reduces shuffle bit width, so that should be a win for
most codegen (if not, it can be inverted).

[pseudo] benchmark cleanups. NFC

- add missing benchmark for lex/preprocess steps
- name benchmarks after the function they're benchmarking, when appropriate
- remove unergonomic "run" prefixes from benchmark names
- give a useful error message if --grammar or --source are missing
- Use realistic example of how to run, run all benchmarks by default.
  (for someone who doesn't know the commands, this is the most useful action)
- Improve typos/wording in comment
- clean up unused vars
- avoid "parseable stream" name, which isn't a great name & not one I expected
  to escape from ClangPseudoMain

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

[mlir] Update LLVMIR Fastmath flags use of MLIR BitEnum functionality

This diff updates the LLVMIR dialect Fastmath flags attribute to use recently
added features of `BitEnum` attributes. Specifically, this diff uses the bit
enum "group" case to represent the `fast` value as an alias for a combination
of other values (`ninf`, `nnan`, ...), instead of using a separate integer
value. (This is in line with LLVM's fastmath flags representation.) This diff
also leverages the `printBitEnumPrimaryGroups` `tblgen` field for concise
enum printing.

The `BitEnum` features were developed for an upcoming diff that adds `fastmath`
support to the arithmetic dialect. This diff simply applies some of the relevant
new features to the LLVM dialect attribute.

Reviewed By: ftynse, Mogball

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

[clangd] Add command-line flag to set background indexing thread priority.

This is a followup to D124715, which changed the default, and it anticipates
future patches raising the priority of Low (which is currently equal to
Background on Windows & Linux).
The main point is to allow users to restore the old behavior, which e.g.
allows efficiency cores to remain idle.

I did consider making this a config setting, this is a more complicated change:
 - needs to touch queue priorities as well as thread priorities
 - we don't know the priority until evaluating the config inside the task
 - users would want the ability to prioritize background indexing tasks relative
   to each other without necessarily affecting thread priority, so using one
   option for both may be confusing
I don't really have a use case, so I prefer the simpler thing.

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

[RISCV] Enable strict assertions in InsertVSETVLI data flow

These asserts are believed to hold after several recent miscompiles have been fixed.  If you see an assertion failure on this change, please toggle the default back and make sure you file a bug with a reproducer.  We may have as yet uncaught miscompiles lurking in this code.

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

[NFC][lldb][trace] Use uint64_t when decoding and enconding json

llvm's json parser supports uint64_t, so let's better use it for the
packets being sent between lldb and lldb-server instead of using int64_t
as an intermediate type, which might be error-prone.

[AMDGPU] gfx11 scalar alu instructions

MC layer support for SOP(scalar alu operations) including encoding
support for s_delay_alu and s_sendmsg_rtn.

Contributors:
Jay Foad <jay.foad@amd.com>

Patch 7/N for upstreaming of AMDGPU gfx11 architecture.

Depends on D125319

Reviewed By: #amdgpu, arsenm

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

[AMDGPU] Add test for no waitcnt before issuing LDS DMA. NFC.

A wait is only needed after the DMA before LDS can be read.

[X86] Rename combineCONCAT_VECTORS\INSERT_SUBVECTOR\EXTRACT_SUBVECTOR to match Opcode name. NFCI.

Its a lot easier to quickly search for the combine when it actually contains the name of the opcode it combines.

[AMDGPU] Add intrinsics llvm.amdgcn.{raw|struct}.buffer.load.lds

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

[mlir][LLVMIR] Use a new way to verify GEPOp indices

Previously, GEPOp relies on `findKnownStructIndices` to check if a GEP
index should be static. The truth is, `findKnownStructIndices` can only
tell you a GEP index _might_ be indexing into a struct (which should use
a static GEP index). But GEPOp::build and GEPOp::verify are falsely
taking this information as a certain answer, which creates many false
alarms like the one depicted in
`test/Target/LLVMIR/Import/dynamic-gep-index.ll`.

The solution presented here adopts a new verification scheme: When we're
recursively checking the child element types of a struct type, instead
of checking every child types, we only check the one dictated by the
(static) GEP index value. We also combine "refinement" logics --
refine/promote struct index mlir::Value into constants -- into the very
verification process since they have lots of logics in common. The
resulting code is more concise and less brittle.

We also hide GEPOp::findKnownStructIndices since most of the
aforementioned logics are already encapsulated within GEPOp::build and
GEPOp::verify, we found little reason for findKnownStructIndices (or the
new findStructIndices) to be public.

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

fix typo error in DivergenceAnalysis.h

Fix a typo error in the comment in DivergenceAnalysis.h

Reviewed By: asbirlea

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

[AArch64] Teach perfect shuffles tables about D-lane movs

Similar to D123386, this adds D-Movs to the AArch64 perfect shuffle
tables, slightly lowering the costs a little more. This is a rough
improvement in general, especially if you ignore mov v0.16b, v2.16b type
moves that are often artefacts of the calling convention.

The D register movs are encoded as (0x4 | LaneIdx), and to generate a D
register move we are required to bitcast into a higher type, but it is
otherwise very similar to the S-lane mov's already supported.

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

[Polly] Mark classes as final by default. NFC.

This make is obivious that a class was not intended to be derived from.

NPM analysis pass can unfortunately not marked as final because they are
derived from a llvm::Checker<T> template internally by the NPM.

Also normalize the use of classes/structs
 * NPM passes are structs
 * Legacy passes are classes
 * structs that have methods and are not a visitor pattern are classes
 * structs have public inheritance by default, remove "public" keyword
 * Use typedef'ed type instead of inline forward declaration

[LV] Regenerate check lines for some tests.

Make sure the auto-generated check lines are up-to-date for some files,
to reduce the test diff in upcoming changes

[clang-cl] Add /Zc:wchar_t- option

Map /Zc:wchar_t- to the cc1 flag -fno-wchar which is already supported.

Reviewed By: thakis

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

[AMDGPU] Add a MIR test for D125567

[llvm][json] Fix UINT64 json parsing

https://reviews.llvm.org/D109347 added support for UINT64 json numeric
types. However, it seems that it didn't properly test uint64_t numbers
larger than the int64_t because the number parsing logic doesn't
have any special handling for these large numbers.

This diffs adds a handler for large numbers, and besides that, fixes the
parsing of signed types by checking for errno ERANGE, which is the
recommended way to check if parsing fails because of out of bounds
errors. Before this diff, strtoll was always returning a number within
the bounds of an int64_t and the bounds check it was doing was completely
superfluous.

As an interesting fact about the old implementation, when calling strtoll
with "18446744073709551615", the largest uint64_t, End was S.end(), even
though it didn't use all digits. Which means that this check can only be
used to identify if the numeric string is malformed or not.

This patch also adds additional tests for extreme cases.

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

[lldb-vscode] Fix data race in lldb-vscode when running with ThreadSanitizer

This patch fixes https://github.com/llvm/llvm-project/issues/54768. A ProgressEventReporter creates a dedicated thread that keeps checking whether there are new events that need to be sent to IDE as long as m_thread_should_exit is true. When the VSCode instance is destructed, it will set m_thread_should_exit to false, which caused a data race because at the same time its ProgressEventReporter is reading this value to determine whether it should quit. This fix simply uses mutex to ensure they cannot read and write this value at the same time.

Committed on behalf of PRESIDENT810

Reviewed By: clayborg, wallace

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

Revert "[llvm-objcopy][test] Add cmp after copy"

This reverts commit 0d863b5b90a2f11e58b0b54d7183cb1577fd3a0b.

Broke a test https://reviews.llvm.org/D125478#3519509

[OpaquePtr][BitcodeReader] Explicitly turn off opaque pointers if we see a typed pointer

Followup to D125735 on the bitcode reader side.

Reviewed By: #opaque-pointers, nikic

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

[OpaquePtr][LLParser] Explicitly turn off opaque pointers if we see a star

If we turn on --opaque-pointers, tests with '*' would use opaque pointers.

Can't really test this without flipping the default value for --opaque-pointers.

Reviewed By: #opaque-pointers, nikic

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

Fix the std::string formatter to report errors in the case where the
string points to unaccessible memory.

The formatter tries to get the data field of the std::string, and to
check whether that fails it just checks that the ValueObjectSP
returned is not empty. But we never return empty ValueObjectSP's to
indicate failure, since doing so would lose the Error object that
tells you why fetching the ValueObject failed.

This patch adds a check for ValueObject::GetError().Success().

I also added a test case for this failure, and reworked the test case
a bit (to use run_to_source_breakpoint). I also renamed a couple of
single letter locals which don't follow the lldb coding conventions.

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

[gn build] Port 76ddbb1ca747

Revert "[clangd] Indexing of standard library"

This reverts commit ecaa4d9662c9a6ac013ac40a8ad72a2c75e3fd3b.

[InstCombine] remove cast-of-signbit to shift transform

The transform was wrong in 3 ways:

1. It created an extra instruction when the source and dest types don't match.
2. It did not account for an extra use of the icmp, so could create 2 extra insts.
3. It favored bit hacks over icmp (icmp generally has better analysis).

This fixes #54692 (modeled by the PhaseOrdering tests).

This is a minimal step to fix the bug, but we should likely invert
this and the sibling transform for the "is negative" pattern too.

The backend should be able to invert this back to a shift if that
leads to better codegen.

This is a reduced try of 3794cc0e9964 - that was reverted because
it could cause infinite loops by conflicting with the related
transforms in this block that create shifts.

[RISCV] Add a test showing incorrect RVV stack alignment

The RISC-V stack is assumed to be aligned to 16 bytes and can handle stack
realignment for larger objects, but the "RVV stack" is only ensured to be
aligned to 8 bytes. This means that objects specified at a larger alignment may
be misaligned, not only for 16-byte-aligned RVV objects that don't trigger
realignment, but also for 32-byte-and-larger-aligned objects which do.

The new test checks a variety of alignment configurations, showing the
misaligned cases.

Reviewed By: reames

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

[LV] Fetch vector loop region once and remember it (NFC).

This avoids an unnecessary lookup and makes the code slightly more
compact.

[gn build] Port ecaa4d9662c9

[clangd] Indexing of standard library

This provides a nice "warm start" with all headers indexed, not just
those included so far.

The standard library is indexed after a preamble is parsed, using that
file's configuration. The result is pushed into the dynamic index.
If we later see a higher language version, we reindex it.

It's configurable as Index.StandardLibrary, off by default for now.

Based on D105177 by @kuhnel

Fixes https://github.com/clangd/clangd/issues/618

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

[RISCV] Drop notion of "strict" vsetvli compatibility

With recent fixes to the dataflow in place, we now never pass
Strict=true to isCompatible, so remove the parameter completely.

Reviewed By: reames

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

[NFC][AIX] Reenable mri1.test

This test is passing now because of D124017 and D123949.

Reviewed By: DiggerLin

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

[IRBuilder] Move insertvalue/extractvalue to fold infrastructure

Move from the old CreateXYZ() to the new FoldXYZ() mechanism.

This change is likely NFC in practice, because I don't think that
the places using InstSimplifyFolder use insertvalue/extractvalue.

Fix release note typo from 6da3d66f

[mlir] vim: add bf16 type

[mlir][licm] Fix debug output with newlines

Fix an unused variable warning in no-asserts build mode

[concepts] Implement dcl.decl.general p4: No constraints on non-template funcs

The standard says:
The optional requires-clause ([temp.pre]) in an init-declarator or
member-declarator shall be present only if the declarator declares a
templated function ([dcl.fct]).

This implements that limitation, and updates the tests to the best of my
ability to capture the intent of the original checks.

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

[pseudo] Add the missing ; terminal for module-declaration rule.

[SLP]Add an  extra check for select minmax reduction to avoid crash.

Need to check if the reduction is still (not)cmp-select pattern min/max
reduction to avoid compiler crash during building list of reduction
operations. cmp-sel pattern provides 2 reduction operations, while
intrinsics - just one.

[pgo] Fix doc typo: thingswith -> things with

The title says it all.

Reviewed By: thakis

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

Enabling the detection of devtoolset-11 toolchain.

This patch allows systems to build the llvm-project with the devtoolset-11
toolchain.

Reviewed By: phosek

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

[DAG] Fold (shl (srl x, c), c) -> and(x, m) even if srl has other uses

If we're using shift pairs to mask, then relax the one use limit if the shift amounts are equal - we'll only be generating a single AND node.

AArch64 has a couple of regressions due to this, so I've enforced the existing one use limit inside a AArch64TargetLowering::shouldFoldConstantShiftPairToMask callback.

Part of the work to fix the regressions in D77804

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

[libc++] Introduce LIBCXX_LIBRARY_VERSION

This allows controlling the current_version linker property on Apple
platforms.

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

[clang] Expose CoawaitExpr's operand in the AST

Previously the Expr returned by getOperand() was actually the
subexpression common to the "ready", "suspend", and "resume"
expressions, which often isn't just the operand but e.g.
await_transform() called on the operand.

It's important for the AST to expose the operand as written
in the source for traversals and tools like clangd to work
correctly.

Fixes https://github.com/clangd/clangd/issues/939

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

[RegAllocGreedy] New hook regClassPriorityTrumpsGlobalness

Add a new TargetRegisterInfo hook to allow targets to tweak the
priority of live ranges, so that AllocationPriority of the register
class will be treated as more important than whether the range is local
to a basic block or global. This is determined per-MachineFunction.

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

[mlir][Tablegen-LSP] Don't link with llvm dylib

This updates 5de12bb703c5104b3fd64ee51c6900d6171d826a
to not link with the dylib since that does not include
the tablegen library.

Should fix flang dylib build failures:
https://lab.llvm.org/buildbot/#/builders/177/builds/5120

[VPlan] Move usesScalars/onlyFirstLaneUsed to VPUser.

Those helpers model properties of a user and they should also be
available to non-recipe users. This will be used in D123537 for a new
exit value user.

Reviewed By: Ayal

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

[AArch64] Extra tests useful for D-lane shuffles. NFC

[JumpThreading] Regenerate test checks (NFC)

[WebAssembly][NFC] Convert IsWasm64 instruction field to 'bit' from string

Extends the cleanup in D125713 to IsWasm64.

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

[WebAssembly][NFC] Convert StackBased instruction field to 'bit' from string

This is (IMHO) cleaner and (objectively) more strongly typed than using strings.

A follow-on patch will do the same for IsWasm64.

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

[X86] Attempt to fold EFLAGS into X86ISD::ADD/SUB ops

We already use combineAddOrSubToADCOrSBB to fold extended EFLAGS results into ISD::ADD/SUB ops as X86ISD::ADC/SBB carry ops.

This patch extends this to also try to fold EFLAGS results with X86ISD::ADD/SUB ops

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

[OpenCL] Do not guard vload/store_half builtins

The vload*_half* and vstore*_half* builtins do not require the
cl_khr_fp16 extension: pointers to `half` can be declared without the
extension and the _half variants of vload and vstore should be
available without the extension.

This aligns the guards for these builtins for
`-fdeclare-opencl-builtins` with `opencl-c.h`.

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

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

[JumpThreading] Don't pass DT to isGuaranteedNotToBeUndefOrPoison()

JumpThreading intentionally does not force updating of the DT
during optimization, because this may be expensive when many CFG
updates and DT calculations are interleaved.

We shouldn't be fetching the DT just for the purpose of calling
isGuaranteedNotToBeUndefOrPoison(), especially as DT availability
doesn't even show benefit in tests.

[DWARFLinker][NFC] Add None value to the DwarfLinkerAccelTableKind enum.

this review is extracted from D86539.

1. Rename AccelTableKind to DwarfLinkerAccelTableKind
   (to differentiate from AccelTableKind from CodeGen/AsmPrinter/DwarfDebug.h)

2. Add None value to the DwarfLinkerAccelTableKind.

3. added 'None' value for 'accelerator' option of dsymutil.

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

[SROA] Avoid postponing rewriting load/store by ignoring lifetime intrinsics in partition's promotability checking

This patch fixes a bug that generates unnecessary packing/unpacking structure code because of incorrectly handling lifetime intrinsic.
For example, a partition of an alloca may contain many slices:
```
Partition [0, 4):
  Slice0: [0, 4) used by: load i32 addr;
  Slice1: [0, 4) used by: store i32 v, addr;
  Slice2: [0, 16) used by lifetime.start(16, addr);
```
When SROA determines if the partition can be promoted, lifetime.start is currently treated as a whole alloca load/store, so Slice0 and Slice1 cannot be promoted at this attempt,
but the packing/unpacking code for Slice0 and Slice1 has been generated.
After rewrite lifetime.start/end intrinsic, SROA tries again with Slice0 and Slice1 and finally promotes them, but redundant packing/unpacking code remaining in the IRs.
This patch changes promotability checking to ignore lifetime intrinsic (they will be rewritten to correct sizes later), so we can promote the real users (load/store) at the first attempt with optimal code.

Reviewed By: nikic

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

[SROA] Precommit test for D124967

[RISCV][NFC] Reword split SP adjustment comments

[mlir] support isa/cast/dyn_cast<Operation *>(operation) again

The support for this has been added by 946311b8938114a37db5c9d42fb9f5a1481ccae1
but then ignored by bc22b5c9a2f729460ffdf7627b3534a8d9f3f767.

This enables one to write generic code that can be instantiated for both
specific operation classes and the common base class without
specialization. Examples include functions that take/return ops, such
as:

```mlir
template <typename FnTy>
void applyIf(FnTy &&lambda, ...) {
  for (Operation *op : ...) {
    auto specific = dyn_cast<function_traits<FnTy>::template arg_t<0>>(op);
    if (specific)
      lambda(specific);
  }
}
```

that would otherwise need to rely on template specialization to support
lambdas that take specific operations and those that take `Operation *`.

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

Reviewed by: rriddle

[SelectionDAG] Support more VP reduction mask operation.

This patch uses VP_REDUCE_AND and VP_REDUCE_OR to replace VP_REDUCE_SMAX,VP_REDUCE_SMIN,VP_REDUCE_UMAX and VP_REDUCE_UMIN for mask vector type.

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

[RISCV][NFC] Fix comment typos in split SP adjustment

[InstCombine] precommit tests for foldSelectToCopysign

[llvm] Fix typo for libxml2 detection

This seems to be a copy-paste from the similar zlib detection code.

Patch By: sthibaul

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

[XCOFF] support writing sections, relocations and symbols for XCOFF64.

This is the second patch to enable the XCOFF64 object writer.

Reviewed By: jhenderson, shchenz

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

[LVI] Compute range for xor

We do have a non-trivial implementation for binaryXor() now.

[CVP] Add test for xor (NFC)

[ConstantRange] Implement binaryXor() using known bits

This allows us to compute known high bits. It's not optimal, but
better than nothing.

[RISCV] Add a test w/ RVV stack objects misaligning non-RVV ones

This patch adds a simple test which demonstrates a miscompilation of
16-byte-aligned scalar (non-RVV) objects when combined with RVV stack
objects.

The RISCV stack is assumed to be aligned to 16 bytes, and this is
guaranteed/assumed to be true when setting up the stack. However, when
the stack contains RVV objects, we decrement the stack pointer by some
multiple of vlenb, which is only guaranteed to be aligned to 8 bytes.
This means that non-RVV objects specifically requiring 16-byte alignment
fall through the cracks and are misaligned. Objects requiring larger
alignment trigger stack realignment and thus should be okay.

Reviewed By: craig.topper

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

[StackColoring] Don't merge slots with differing StackIDs

The documentation for this specifically mentions that this should not
happen. We could think about adding target hooks to permit it (and how
to merge IDs) in the future if that is desirable.

This specific test case was merging a scalable-vector slot into a
non-scalable one and dropping the notion of scalability, meaning we
failed to allocate enough stack space for the object.

Reviewed By: arsenm, MaskRay, sdesmalen

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

[KnownBits] Add operator==

Checking whether two KnownBits are the same is somewhat common,
mainly in test code.

I don't think there is a lot of room for confusion with "determine
what the KnownBits for an icmp eq would be", as that has a
different result type (this is what the eq() method implements,
which returns Optional<bool>).

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

[flang] Add one semantic check for elemental call arguments

As Fortran 2018 15.8.1(3), in a reference to an elemental procedure, if
any argument is an array, each actual argument that corresponds to an
INTENT (OUT) or INTENT (INOUT) dummy argument shall be an array. Add
this semantic check.

Reviewed By: klausler

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

[flang][OpenMP] Support lowering to MLIR for ordered clause

This supports the lowering parse-tree to MLIR for ordered clause in
worksharing-loop directive. Also add the test case for operation
conversion.

Part of this patch is from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project.

Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com>
Reviewed By: kiranchandramohan, NimishMishra

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

[RISCV] Support getHostCpuName for sifive-u74

Reviewed By: kito-cheng

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

[mlir][LLVMIR] Add support for translating insertelement/extractelement.

Add support for translating llvm::InsertElement and llvm::ExtractElement.

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

[Frontend] [Coroutines] Emit error when we found incompatible allocation
function in promise_type

According to https://cplusplus.github.io/CWG/issues/2585.html, this
fixes https://github.com/llvm/llvm-project/issues/54881

Simply, the clang tried to found (do lookup and overload resolution. Is
there any better word to use than found?) allocation function in
promise_type and global scope. However, this is not consistent with the
standard. The standard behavior would be that the compiler shouldn't
lookup in global scope in case we lookup the allocation function name in
promise_type. In other words, the program is ill-formed if there is
incompatible allocation function in promise type.

Reviewed By: erichkeane

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

Revert "[dwarf] Emit a DIGlobalVariable for constant strings."

This reverts commit 4680982b36a84770a1600fc438be8ec090671724.

Broke a fuchsia windows bot. More details in the review:
https://reviews.llvm.org/D123534

[nfc][lld-macho] Follow up fixes to bd9e46815d73e4236c207bad8b5c54e7188154d7

Need -DAG in the first expect statement too

[mlir][sparse] Moved _mlir_ciface_newSparseTensor closer to its macros

This is a followup to D125431, to keep from confusing the machinery that generates diffs (since combining these two changes into one would obfuscate the changes actually made in the previous differential).

Depends On D125431

Reviewed By: aartbik

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

[WebAssembly] Update relaxed SIMD opcodes and names

to reflect the latest state of the proposal:
https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md#binary-format.
Moves code around to match the instruction order from the proposal, but the only
functional changes are to the names and opcodes.

Reviewed By: aheejin

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

[nfc][lld-macho] Fixed test from https://reviews.llvm.org/D125732

Details:
The test was incorrectly expecting the error messages for the export symbols to have a particular order.
It shouldn't because the export symbol list is processed concurrently.

[lld-macho] Temporarily disable test on windows
The metadata seems to be demangled differently

[RISCV] Use classic dataflow for VSETVLI insertion

Our current implementation of the InsertVSETVLI dataflow allows phase 3 to arrive at a different block end state than the data flow in phase 1/2 computed. This arises because a block which contains instructions (e.g. load or stores) which don't consume all the incoming bits of the VL/VTYPE can be compatible with multiple incoming states. The algorithm effectively changes the SEW on such instructions, and propagates the prior state forward. As phase 3 uses the block input state for this propagation, but phase 1/2 doesn't, this can result in different block end states.

If we don't correct for it, this discrepancy can result in miscompiles. This was the source of multiple recent bugs. However, by now we have fixes for all known correctness issues.

The basic strategy we use is to insert a compensation vsetvli to bring the block state leaving the block back into consistency with the one computed. This is correct, but results in extra vsetvlis being placed at the end of blocks.

This change adjusts the phase 1/2 algorithm to propagate the incoming block state through the block, allowing the compatibility rules to modify the end state. The algorithm may need to run slightly more iterations, but the end result is consistent with what phase 3 does.

The benefit of doing this is two fold.

First, we reverse some of the code quality introductions introduced in the functional fixes.

Second, we simplify the invariants, and allow the strict assertions to be enabled. Several humans, myself included, have found it quite surprising that invariant didn't hold already, and arguably that confusion is the cause of several of our recent miscompiles in this code.

The downside to this patch is that the dataflow may require additional iterations to stabilize. In the worse case, we go from O(Edges) to O(E + UniquePaths) as the incoming state (and thus the outgoing one) can now change once for each path from the entry block.

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

[RISCV] Fix missing vsetvli in transparent block case

We've got a lurking problem with our data flow implementation where different phases disagree, resulting in possible miscompiles. D119518 introduced a workaround, but failed to consider blocks which only contain load/stores compatible with their incoming state.

When I went to rebase and simplify D125232, it turned out that not all of the correctness issues had been fixed yet after all. This is the correctness fix accidentally embedded in the original more complicated version.

Note that the test changes here are mostly regressions. It's worth noting that the simplified version of D125232 exactly reverses all the non-functional diffs in the test caused here. D125232 should be the immediate following commit.

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

[test-suite][cmake] sort unit test targets

This patch sorts unit test targets into directories corresponding to the
test source file directories to improve target navigation.

Reviewed By: smeenai

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

[dwarf] Emit a DIGlobalVariable for constant strings.

An upcoming patch will extend llvm-symbolizer to provide the source line
information for global variables. The goal is to move AddressSanitizer
off of internal debug info for symbolization onto the DWARF standard
(and doing a clean-up in the process). Currently, ASan reports the line
information for constant strings if a memory safety bug happens around
them. We want to keep this behaviour, so we need to emit debuginfo for
these variables as well.

Reviewed By: dblaikie, rnk, aprantl

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