This code is only for riscv, but use the CHECK macro to avoid unused
parameters problems if assert is not defined.

Reference: https://github.com/openbsd/src/blob/master/sys/sys/exec_elf.h

This patch introduces a new version for the basic block sections profile
as was requested in D158442, while keeping backward compatibility for
the old version.

The new encoding is as follows:
```
m <module_name>
f <function_name_1> <function_name_2>...
c <bb_id_1> <bb_id_2> <bb_id_3>
c <bb_id_4> <bb_id_5>
...
```
Module name specifier (starting with 'm') is optional and allows
distinguishing profiles for internal-linkage functions with the same
name. If not specified, profile will be applied to any function with the
same name.
Function name specifier (starting with 'f') can specify multiple
function name aliases.
Finally, basic block clusters are specified by 'c' and specify the
cluster of basic blocks, and the internal order in which they must be
placed in the same section.

The MI Peephole pass has grown to include a large number of transformations over the years. Many of the transformations require re-computation of kill flags but don't do a good job of re-computing them. This causes us to have very common failures when the compiler is built with expensive checks. Over time, we added and augmented a function that is supposed to go and fix up kill flags after each transformation but we keep missing cases.
This patch does the following:
- Removes the function to re-compute kill flags
- Adds LiveVariables to compute and maintain kill flags while transforming code
- Adds re-computation of kill flags for the post-RA peepholes for each block that contains a transformed instruction

Reviewed By: stefanp

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

There was an issue with relative vtables when two TU's which define the
same vtable object are built with different default visibilities. Some
TU's are built with -fvisibility=hidden in the code base, grep for
CMAKE_CXX_VISIBILITY_PRESET to find them. Our whole toolchain, is
statically linked, and built with -fPIE anyway, so the cost of
overriding local CMAKE_CXX_VISIBILITY_PRESET properties is not high.
I've counted that adding this flag increases our llvm binary by 13
relocations. Frankly I'm not sure where those are even coming from.

It would be preferable to use hidden visibility, but that breaks liblld.
This can be solved by setting LLDB_EXPORT_ALL_SYMBOLS. After that some
ORC tests fail which do symbolic lookup in the tests. It seems that
setting CMAKE_CXX_VISIBILITY_PRESET=hidden will not be worth the
maintenance burden. Setting it to default works to unblock using
relative vtables, so we can just go with that.

This reverts commit 36bd5bd8.

This change is causing a test failure on several build bots:
- https://lab.llvm.org/buildbot/#/builders/139/builds/50255
- https://lab.llvm.org/buildbot/#/builders/216/builds/27735
- https://lab.llvm.org/buildbot/#/builders/247/builds/9334

This patch fixes:

  lldb/include/lldb/Symbol/Function.h:270:3: error:
  'lldb_private::CallEdge' has virtual functions but non-virtual
  destructor [-Werror,-Wnon-virtual-dtor]

Remove the paper trail warning from dsymutil and the DWARF linker. The
original purpose of this functionality was to leave a paper trail in the
output artifact about missing object files. The current implementation
however has diverged and is the source of a pretty serious bug:

- In the debug map parser, missing object files are not the only
  warnings we emit. When paper trail warnings are enabled, all of them end
  up in the dSYM which wasn't the goal.
  
- When warnings are associated with a object file in the debug map, it
  is skipped by the DWARF linker. This only makes sense if the object file
  is missing and is obviously incorrect for any other type of warning
  (such as a missing symbol).

The combination of the two means that we can generate broken DWARF when
the feature is enabled. AFAIK it was only used by Apple and nobody I
spoke to has relied on it, so rather than fixing the broken behavior I
propose we remove it.

This reverts commit db51e572.

Reverted while I investigate build failures, e.g.
https://lab.llvm.org/buildbot/#/builders/234/builds/12900

No testcase: This code generates an in-memory object file that is shared with
the debugger. The object file is malformed in ways that don't matter to the
debugger, but mean that it can't be inspected by most tools.

This set of commits resolves some of the issues with elemental calls producing
results that may require finalization, and also some memory leak issues due to
the missing deallocation of allocatable components of the temporary buffers
created by the bufferization pass.

- [flang][runtime] Expose Finalize API for derived types.

- [flang][hlfir] Add 'finalize' attribute for DestroyOp.

- [flang][hlfir] Postpone result finalization for elemental calls.

    The results of elemental calls generated inside hlfir.elemental must not
    be finalized/destructed before they are copied into the resulting
    array. The finalization must be done on the array as a whole
    (e.g. there might be different scalar and array finalization routines).
    The finalization work is left to the hlfir.destroy corresponding
    to this hlfir.elemental.

- [flang][hlfir] Tighten requirements on hlfir.end_associate operand.

    If component deallocation might be required for the operand of
    hlfir.end_associate, we have to be able to get the variable
    shape/params to create a descriptor for calling the runtime.
    This commit adds verification that we can do so.

- [flang][hlfir] Lower argument clean-ups using valid hlfir.end_associate.

    The operand must be a Fortran entity, when allocatable component
    deallocation may be required.

- [flang][hlfir] Properly clean-up temporary buffers in bufferization pass.

    This commit combines changes for proper finalization and component
    deallocation of the temporary buffers. The finalization part
    relates to hlfir.destroy operations with 'finalize' attribute.
    The component deallocation might be invoked for both hlfir.destroy
    and hlfir.end_associate, if the operand is of a derived type
    with allocatable component(s).

The changes are mostly in one function, so I decided not to split them.

- [flang][hlfir] Disable optimizations for hlfir.elemental requiring finalization.

    If hlfir.elemental is coupled with hlfir.destroy with 'finalize' attribute,
    the temporary array result of hlfir.elemental needs to be created
    for the purpose of finalization. We cannot do certain optimizations
    on such hlfir.elemental operations.

    I was not able to come up with a test for the OptimizedBufferization pass,
    but I put the check there as well.

This prevents undefined vtable errors when linking these libraries from
out-of-tree. I'm facing this issue as I work on my new language plugin.

`setInsertFencesForAtomic` is `shouldInsertFencesForAtomic` now.

`rdty` of `PseudoLoad` is always `GPR` and it will never be `GPR` for
`PseudoFloatLoad`.

…ines.

We have an existing test that shows benefit from redundant_and and
identity combines so use them as a starting point.

…verting VMV_V_X to VMV_X_S.

Instruction selection knows the bits past EltWidth are ignored, we
should do the same here.

That can prevent compilation with -Werror and -std=c++20:
mutex.h:63:7: error: increment of object of volatile-qualified type 'volatile u32' (aka 'volatile unsigned int') is deprecated [-Werror,-Wdeprecated-volatile]

GetObjectPointer (and other related methods) do not need `ConstString`
parameters. The string parameter in these methods boil down to getting a
StringRef and calling `StackFrame::GetValueForVariableExpressionPath`
which takes a `StringRef` parameter. All the users of `GetObjectPointer`
(and related methods) end up creating ConstString objects to pass to
these methods, but they could just as easily be StringRefs (potentially
saving us some allocations in the StringPool).

This patch fixes:

  llvm/lib/ProfileData/Coverage/CoverageMapping.cpp:219:5: error:
  default label in switch which covers all enumeration values
  [-Werror,-Wcovered-switch-default]

Rationale:
The term "sparse compiler", although dear to my heart, is often mistaken
as a completely separate compiler, and not a pass within a full compiler
pipeline. Therefore, we start migrating to the term "sparsifier".

This patch set the integration test's linking options to be the same one
used in the hermetic tests.

In particular, by removing -nostdlib the tests are linked with
libgcc/compiler-rt and this fixes an issue undefined reference to
__udivdi3 and __umoddi3 in rv32.

This causes stack overflows for real-world coverage reports.

Ran $ build/bin/llvm-lit -a llvm/test/tools/llvm-cov locally and passed.

Co-authored-by: Qing Shen <qingshen@google.com>

Updates:
1. Added more invalid encodings to test the robustness of the new syntax
2. Changed the asserts that caused crashing into returning booleans
3. Modified some error messages to make them clearer and handled
failures in parsing quotes as keyword for level formats and properties.

Before this change, ErrnoSetterMatcher only allowed testing for equality
of the expected return and errno values. This change extends it to allow
testing for expected inequalities of the return and errno values. The
test libc.test.src.stdio.fileop_test has been updated to use the
ErrnoSetterMatcher with tests for inequalities.

Sometimes with mask vectors that have been widened, there is a
CopyToRegClass node in between the VMSET and the CopyToReg.

This is a resurrection of https://reviews.llvm.org/D148524, and is
needed to
remove the mask operand when it's extracted from a subvector as planned
in
https://github.com/llvm/llvm-project/pull/66267#discussion_r1331998919

Pulled out as NFC(ish) pre-commit from D159533

This should limit how many commits we need to fetch and should be faster.

And simplify formulas containing true/false
It's unclear to me how useful this is, it does make formulas more
conveniently self-contained now (we can usefully print them without
carrying around the "true/false" labels)

(while here, simplify !!X to X, too)

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

A common practice involves the creation of multiple `mbarrier` objects,
see an example below. This is particularly valuable in scenarios like
software pipelining for GEMM, where we need to generate multiple
barriers dynamically use and wait them in a loop.

PR improves `nvgpu.mbarrier.barrier` type into the
`nvgpu.mbarrier.group`. All `mbarrier` related Ops now uses this type.
Consequently, these Ops are now capable of managing multiple barriers
seamlessly.

Having `num_barriers = 4` helps us to locate mbarrier object(s) into
static shared memory. We could make the value dynamic that requires
dynamic shared memory it would complicate the codegen.

```
%barriers = nvgpu.mbarrier.create -> !nvgpu.mbarrier.group<3, num_barriers = 4>
nvgpu.mbarrier.init %barriers[%c0], %num_threads : !nvgpu.mbarrier.group<3, num_barriers = 4>
nvgpu.mbarrier.init %barriers[%c1], %num_threads : !nvgpu.mbarrier.group<3, num_barriers = 4>
nvgpu.mbarrier.init %barriers[%c2], %num_threads : !nvgpu.mbarrier.group<3, num_barriers = 4>
nvgpu.mbarrier.init %barriers[%c3], %num_threads : !nvgpu.mbarrier.group<3, num_barriers = 4>
...
scf.for %i = %c0 to %n step %c1 {
  nvgpu.mbarrier.try_wait %barriers[ (i % 4) ] ... 

  // ... Do work once mbarrier is ready 

  nvgpu.mbarrier.arrive.expect_tx %barriers[ (i + 3 % 4) ] ... 
}
```
We will have mbarrier usages like below: 
```
expect_tx[0]
expect_tx[1]
expect_tx[2]
Loop:
 try_wait mbarrier[0], expect_tx[3]
 try_wait mbarrier[1], expect_tx[0]
 try_wait mbarrier[2], expect_tx[1]
 try_wait mbarrier[3], expect_tx[2]
...
```

Reordering of possible strided nodes in bottom-to-top order requires
top-to-bottom reordering of the operands of such nodes, which is not
supported. Need to disable reordering of strided operands to avoid
compiler crashes.

Prior to this the command would simply crash when run on a running
process.

Of the three register commands, "info" was the only one missing these
requirements. On some level it makes sense because you're not going to
read a value or modify anything, but practically I think lldb assumes
any time you're going to access register related stuff, the process
should be paused.

I noticed this debugging with a remote gdb stub, so I've recreated that
scenario using attach in a new test case.

This reverts commit 0f864c7b due to
failures on expensive checks.

This cs_chain and cs_chain_preserve use InReg attribute to indicate
argument passed through SGPR.

Patch by: Acim Maravic

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

Unlike the per-lane mov*dup broadcast shuffles, broadcastsd/ss need port5 to splat across lanes

Found while reviewing a llvm-exegesis capture (and matches Agner + uops.info numbers) - I can't find any more easy wins from these captures so that will be it for now.

Found while reviewing a llvm-exegesis capture (and matches Agner + uops.info numbers)