HLSL doesn't have a C++ runtime that supports `atexit` registration. To
enable global destructors we instead rely on the `llvm.global_dtor`
mechanism.

This change disables `atexit` generation for HLSL and updates the HLSL
code generation to call global destructors on the exit from entry
functions.

Depends on D132977.

Reviewed By: aaron.ballman

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

Modify `SBTypeNameSpecifier` and `lldb_private::TypeMatcher` so they
have an enum value for the type of matching to perform instead of an
`m_is_regex` boolean value.

This change paves the way for introducing formatter matching based on
the result of a python callback in addition to the existing name-based
matching. See the RFC thread at
https://discourse.llvm.org/t/rfc-python-callback-for-data-formatters-type-matching/64204
for more details.

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

In GFX10, there is no advantage to shrinking these instructions pre-RA,
so this just saves a bit of work.

In GFX11 there is an advantage to *not* shrinking them pre-RA, because
the register classes for 16-bit operands are less restrictive in the
VOP3 form than in the shrunk form. This patch is a prerequisite for
actually setting up those register classes correctly for 16-bit vs
non-16-bit operands.

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

When a select is converted to a branch and load instructions are sinked to the true/false blocks,
lifetime intrinsics (if present) could be made unsound if not moved.

This conservatively moves all lifetime intrinsics in a transformed BB to the end block to ensure
preserved lifetime semantics.

Reviewed By: davidxl

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

The DXContainer is pretty primitive, but doesn't support COMDAT. We need
to set that in the Triple so that Clang won't try to emit COMDATs.

Reviewed By: gchatelet

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

Per original review, only one test needed the MIR output checks.  Copy that to it's own file, and use auto-gen for all three files.

This adds bytecode support for DenseArrayAttr, DenseIntOrFpElementsAttr,
DenseStringElementsAttr, and SparseElementsAttr.

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

Boolean splats currently can't roundtrip via the "raw" DenseElementsAttr
API. This is because internally we treat true splats in some cases as "1"(one bit set)
and in other cases as "0xFF"(all bits set). This commit cleans up this handling to
consistently use 0xFF (all bits set) as the value for a splat of true.

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

This is necessary/useful for building generic tooling that can roundtrip external
resources without needing to explicitly handle them. For example, this allows
for viewing the resources encoded within a bytecode file without having to
explicitly know how to process them (e.g. making it easier to interact with a
reproducer encoded in bytecode).

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

Resources are encoded in two separate sections similarly to
attributes/types, one for the actual data and one for the data
offsets. Unlike other sections, the resource sections are optional
given that in many cases they won't be present. For testing,
bytecode serialization is added for DenseResourceElementsAttr.

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

We don't need to populate a string table, so we don't need to pre-parse the
remarks.

Split the bitstream2yaml and yaml2bitstream cases up so that we can avoid the
extra remark traversal in the bitstream2yaml case.

This kills the TODO.

Reviewed By: thakis

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

See https://discourse.llvm.org/t/use-bazelisk-for-bazel-buildbots/65188.

Reviewed By: mehdi_amini

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

Unary shuffles such as <0,2,4,6,8,10,12,14> or <1,3,5,7,9,11,13,15>
where half the elements are returned, can be lowered using vnsrl.

SelectionDAGBuilder lowers such shuffles as a build_vector of
extract_elements since the mask has less elements than the source.
To fix this, I've enable the extractSubvectorIsCheapHook to allow
DAGCombine to rebuild the shuffle using 2 extract_subvectors preceding
the shufffle.

I've gone very conservative on extractSubvectorIsCheapHook to minimize
test impact and match what we have test coverage for. This can be
improved in the future.

Reviewed By: reames

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

Reviewed By: lntue

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

This is particularly a problem for alias construction, where you might
want to have a backtick surrounded option in the alias.  Before this
patch:

command alias expression -Z \`argc\` -- argv

for instance would be rendered as:

expression -Z argc -- argv

and would fail to work.

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

Add pointer-to-member example to AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack.md

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

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

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

This hook is currently only used by CodeGenPrepare, which will sink *and
duplicate* an 'and' into a block that has an 'icmp 0' user of it if the
hook returns true.

This hook is less useful for RISC-V than for targets like AArch64 that
have a TBZ (test bit and branch if zero instruction), but may still be
profitable if Zbs is available and a BEXTI can be selected.

Conservatively, we return false even if Zbs is enabled for any masks
that fit in the ANDI immediate because it's possible the only use is a
branch on the result, and ANDI+BNEZ => BEXTI+BNEZ isn't a profitable
transformation.

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

https://reviews.llvm.org/rGa3172df59c32aac48c113eb7d6a1324aaa95c474 breaks
check-lldb gn build.

Reviewed By: thakis

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

I went over the output of the following mess of a command:

  (ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel
  --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E
  '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' |
  aspell pipe -W3 | grep : | cut -d' ' -f2 | less)

and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).

Differential revision: https://reviews.llvm.org/D131122

The following replacements have been changed to `%mlir_lib_dir`:

- `%linalg_test_lib_dir`
- `%cuda_wrapper_library_dir`
- `%spirv_wrapper_library_dir`
- `%vulkan_wrapper_library_dir`
- `%mlir_runner_utils_dir`
- `%mlir_integration_test_dir`

If there are no requests to delay submission, I plan to submit this on 9/13/2002 (Tuesday).

See also PSA: https://discourse.llvm.org/t/psa-removing-mlir-lit-test-replacements/65124

Reviewed By: herhut

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

All the functions in this file should be static to avoid ODR violations.

Previously, we would add entries to DataInCodeSection in the order they
appeared in input files. Because of this, entries would not be sorted if
sections were reordered due to e.g. `-order_file` or call graph profile
sorting. ld64 always keeps data-in-code information sorted.

This commit also fixes an incorrect assertion. The original assertion
from D103006 used to check that data-in-code entries are sorted in the
input objects -- likely because we use binary search on that data. In
D115556, the assertion was moved into `collectDataInCodeEntries`, but
the checked variable's name was not changed, so it ended up checking the
final contents of the DataInCodeSection.

We no longer crash when building LLVM with PGO using an asserts build of
LLD as the linker.

Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=1265937

Numbers for linking the Chromium Framework reproducer from #48001, which
has 6829 data-in-code entries:

  x before
  + after
      N           Mi...

subi(addi(a, b), b) -> a
subi(addi(a, b), a) -> b
subi(subi(a, b), a) -> subi(0, b)

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

I encountered an issue where `p &variable` was finding an incorrect address for
32-bit PIC ELF files loaded into a running process.  The problem was that the
R_386_32 ELF relocations were not being applied to the DWARF section, so all
variables in that file were reporting as being at the start of their respective
section.  There is an assert that catches this on debug builds, but silently
ignores the issue on non-debug builds.

In this changeset, I added handling for the R_386_32 relocation type to
ObjectFileELF, and a supporting function to ELFRelocation to differentiate
between DT_REL & DT_RELA in ObjectFileELF::ApplyRelocations().

Demonstration of issue:
```
[dmlary@host work]$ cat rel.c
volatile char padding[32] = "make sure var isnt at .data+0";
volatile char var[] = "test";
[dmlary@host work]$ gcc -c rel.c -FPIC -fpic -g -m32

[dmlary@host work]$ lldb ./exec
(lldb) target create "./exec"
Current executable set to '/home/dmlary/src/work/exec' (i386).
(lldb) process launch --stop-at-entry
Process 21278 stopped
* thread #1, name = 'exec', stop reason = signal SIGSTOP
    frame #0: 0xf7fdb150 ld-2.17.so`_start
ld-2.17.so`_start:
->  0xf7fdb150 <+0>: movl   %esp, %eax
    0xf7fdb152 <+2>: calll  0xf7fdb990                ; _dl_start

ld-2.17.so`_dl_start_user:
    0xf7fdb157 <+0>: movl   %eax, %edi
    0xf7fdb159 <+2>: calll  0xf7fdb140
Process 21278 launched: '/home/dmlary/src/work/exec' (i386)

(lldb) image add ./rel.o
(lldb) image load --file rel.o .text 0x40000000 .data 0x50000000
section '.text' loaded at 0x40000000
section '.data' loaded at 0x50000000

(lldb) image dump symtab rel.o
Symtab, file = rel.o, num_symbols = 13:
               Debug symbol
               |Synthetic symbol
               ||Externally Visible
               |||
Index   UserID DSX Type            File Address/Value Load Address       Size               Flags      Name
------- ------ --- --------------- ------------------ ------------------ ------------------ ---------- ----------------------------------
[    0]      1     SourceFile      0x0000000000000000                    0x0000000000000000 0x00000004 rel.c
[    1]      2     Invalid         0x0000000000000000                    0x0000000000000020 0x00000003
[    2]      3     Invalid         0x0000000000000000 0x50000000 0x0000000000000020 0x00000003
[    3]      4     Invalid         0x0000000000000025                    0x0000000000000000 0x00000003
[    4]      5     Invalid         0x0000000000000000                    0x0000000000000020 0x00000003
[    5]      6     Invalid         0x0000000000000000                    0x0000000000000020 0x00000003
[    6]      7     Invalid         0x0000000000000000                    0x0000000000000020 0x00000003
[    7]      8     Invalid         0x0000000000000000                    0x0000000000000020 0x00000003
[    8]      9     Invalid         0x0000000000000000                    0x0000000000000020 0x00000003
[    9]     10     Invalid         0x0000000000000000                    0x0000000000000020 0x00000003
[   10]     11     Invalid         0x0000000000000000                    0x0000000000000020 0x00000003
[   11]     12   X Data            0x0000000000000000 0x50000000 0x0000000000000020 0x00000011 padding
[   12]     13   X Data            0x0000000000000020 0x50000020 0x0000000000000005 0x00000011 var

(lldb) p &var
(volatile char (*)[5]) $1 = 0x50000000
```

Reviewed By: labath

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

This patch fixes:

  llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:5879:5: error:
  expression result unused [-Werror,-Wunused-value]

D129370 started hoisting allocas across stacksave/stackrestore
boundaries which is wrong.

Reviewed By: chill, rnk

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

Make main/alternate operation selection logic for CmpInst
consistent across SLP vectorizer.

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

This is the ultimate fallback code if UADDO isn't supported.

If the target uses 0/1 we used one compare, but if the target doesn't
use 0/1 we emitted two compares. Regardless of boolean constants we
should only need to check that the Result is less than one of the
original operands. So we only need one compare.

Reviewed By: spatel

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

Adds MVT::v256i2, MVT::v128i4.

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

Introduce the additional "transform-dialect-print-top-level-after-all" debug
category that allows the user to print the paylaod IR after each transformation
performed by the transform dialect. This is useful for understanding and
debugging the effects of individual transformations in complex transformations
scripts, including in downstreams, without having to modify the transformation
script itself.

Reviewed By: mravishankar

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

[RISCV] Return true in hasBitTest when Zbs is enabled and update BEXTI pattern for resulting canonicalisation

As the Zbs extension includes bext[i] for bit extract, we can
unconditionally return true from this hook. This hook causes the DAG
combiner to perform the following canonicalisation:

  and (not (srl X, C)), 1 --> (and X, 1<<C) == 0
  and (srl (not X), C)), 1 --> (and X, 1<<C) == 0

As simply changing the hook causes a codegen regression, this patch also
modifies a BEXTI pattern to match this canonicalised form.

As BSETINVMask is now used for BEXT as well as BSET and BINV, it has
been renamed to the more generic SingleBitSetMask.

There is one codegen change in bittest.ll for bittest_31_i64 (NOT+BEXTI
rather than NOT+SRLIW). This is neutral in terms of code quality.

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

We use the saturating behavior of fcvt.wu.h/s/d but forgot to
take into account that fcvt.wu will sign extend the saturated
result. According to computeKnownBits a promoted FP_TO_UINT_SAT
is expected to zero extend the saturated value.

In many case the upper bits aren't be demanded so this wouldn't
be an issue. But if we computeKnownBits caused an AND to be removed
it would be a bug.

This patch inserts an AND during to zero the upper bits.

Unfortunately, this pessimizes code if we aren't able to tell if
the upper bits are demanded. To fix that we could custom type
promote the FP_TO_UINT_SAT with SEXT_INREG after it, but I'll
leave that for future work.

I haven't found a failure from this, I was revisiting the code to
add vector support and spotted it.

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

This revision significantly improves and tests the broadcast behavior of vector.warp_execute_on_lane_0.

Previously, the implementation of the broadcast behavior of vector.warp_execute_on_lane_0
assumed that the broadcasted value was always of scalar type.

This is not necessarily the case.

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