Merge allows a user to merge different files (tbds for now or dylibs in
the future) to emit out a single tbd with all input contents. This does
require that all inputs represent the same library.

If we are using entirely vslide1downs to initialize an otherwise undef
vector, we end up with an implicit_def as the source of the first
vslide1down. This register has to be allocated, and creates false
dependencies with surrounding code.

Instead, start our sequence with a vmv.v.x in the hopes of creating a
dependency breaking idiom. Unfortunately, it's not clear this will
actually work as due to the VL=0 special case for T.A. the hardware has
to work pretty hard to recognize that the vmv.v.x actually has no source
dependence. I don't think we can reasonable expect all hardware to have
optimized this case, but I also don't see any downside in prefering it.

The fields are still kept as public for now since our tooling accesses
them. Will change them to private visibility in a later patch.

This patch handles `poison` elements of non-splat vectors in
`computeKnownBits`. It addresses test changes after I delete the
duplicate logic in https://github.com/llvm/llvm-project/pull/72535.

See also @nikic's comment:
https://github.com/llvm/llvm-project/pull/72535#pullrequestreview-1736991557

Currently the only way to add or remove entrypoints is to modify the
entrypoints.txt file for the current target. This isn't ideal since
a user would have to carry a diff for this file when updating their
checkout. This patch adds a basic mechanism to allow the user to remove
entrypoints without modifying the repository.

We intend to remove the base specialization in LLVM 19, not LLVM 18. We
simply forgot to update the deprecation message accordingly.

Now that the `parallel` support has landed, add the other 'trivial' to
implement ones that don't require any additional work other than adding
them to the StringSwitch.

Reviewers: thurstond, kstoimenov

Reviewed By: thurstond, kstoimenov

Pull Request: https://github.com/llvm/llvm-project/pull/72686

As the first real parsing effort for the OpenACC implementation effort,
this implements the parsing for first construct/directive name. This
does not do any semantic analysis, nor any of the clauses. Those will
come in a future patch.

For the time being, we warn when we hit a point that we don't implement
the parsing for either of these situations.

Remove unused functions in parser.

This showed up when simplifying some large testcase, where the cfi directives
became out of sync with the proc's they enclose.

rdar://111459507

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

This reverts commit 4172fcc1.

Opaque ptr cleanup effort (NFC)

llvm-gsymutil allows address ranges to overlap. There was a bug where if
we had debug info for a function with a range like [0x100-0x200) and a
symbol at the same start address yet with a larger range like
[0x100-0x300), we would randomly get either only information from the
first or second entry. This could cause lookups to fail due to the way
the binary search worked.

This patch makes sure that when lookups happen we find the first address
table entry that can match an address, and also ensures that we always
select the first FunctionInfo that could match. FunctionInfo entries are
sorted such that the most debug info rich entries come first. And if we
have two ranges that have the same start address, the smaller range
comes first and the larger one comes next. This patch also adds the
ability to iterate over all function infos with the same start address
to always find a range that contains the address.

Added a unit test to test this functionality that failed prior to this
fix and now succeeds.

Also fix an issue when dumping an entire GSYM file that has duplicate address entries where it used to always print out the binary search match for the FunctionInfo, not the actual data for the address index.

This function is never used, neither here nor downstream in the Swift
fork. As far as I can tell, the same is true for the corresponding
eErrorTypeMachKernel but as that's part of the SB API we cannot remove
that.

This reverts commit a4051932.

It broke: lld/test/COFF/gc-dwarf-eh.s

foldMemoryOperand looks at pairs of instructions (generally a load to
virt reg then use of the virtreg, or def of a virtreg then a store) and
attempts to combine them.  This can reduce register pressure.

A prior commit added the ability to mark such a MachineOperand as
foldable. In terms of INLINEASM, this means that "rm" was used (rather
than just "r") to denote that the INLINEASM may use a memory operand
rather than a register operand. This effectively undoes decisions made
by the instruction selection framework.  Callers will be added in the
register allocation frameworks. This has been tested with all of the
above (which will come as follow up patches).

Thanks to @topperc who suggested this at last years LLVM US Dev Meeting
and @qcolombet who confirmed this was the right approach.

Link: https://github.com/llvm/llvm-project/issues/20571

This reverts commit 0fd5dc94.

The original commit removed DIArgLists from being in an MDNode map, but did
not insert a new `delete` in the LLVMContextImpl destructor. This
reapply adds that call to delete, preventing a memory leak.

Add a new API in SBTarget to Load Core from a SBFile.
This will enable a target to load core from a file descriptor.
So that in coredumper, we don't need to write core file to disk, instead
we can pass the input file descriptor to lldb directly.


Test:
```
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> file_object = open("/home/hyubo/210hda79ms32sr0h", "r")
>>> fd=file_object.fileno()
>>> file = lldb.SBFile(fd,'r', True)
>>> error = lldb.SBError()
>>> target = lldb.debugger.CreateTarget(None)
>>> target.LoadCore(file,error)
SBProcess: pid = 56415, state = stopped, threads = 1
```

In openai/triton#2483 I've encountered a bug in the NVPTX codegen. Given
`load<8 x half>` followed by `fpext to <8 x float>` we get

```
ld.shared.v4.b16 	{%f1, %f2, %f3, %f4}, [%r15+8];
ld.shared.v4.b16 	{%f5, %f6, %f7, %f8}, [%r15];
```

Which loads float16 values into float registers without any conversion
and the result is simply garbage.

This PR brings `v8f16` and `v8bf16` into line with the other vector
types by expanding it to load + cvt.

cc @manman-ren @Artem-B @jlebar

If we already have a YMM/ZMM constant that a smaller XMM/YMM has matching lower bits, then ensure we reuse the same constant pool entry.

Extends the similar combines we already have to reuse VBROADCAST_LOAD/SUBV_BROADCAST_LOAD constant loads.

This is a mainly a canonicalization, but should make it easier for us to merge constant loads in a future commit (related to both #70947 and better X86FixupVectorConstantsPass usage for #71078).

This showed up when simplifying some large testcase, where the cfi directives
became out of sync with the proc's they enclose.

rdar://111459507

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

Reverts llvm/llvm-project#72147

Reverted due to buildbot failure:
https://lab.llvm.org/buildbot/#/builders/5/builds/38410

This test exposes a bug where we violate constant bus restriction.

The RiscV64 48-bit mappings introduced in
46cb8d9a

 necessitated changing
RestoreAddr to use 4-bits as the indicator. This roughly halves the
speed of RestoreAddr, because it is now brute-force testing addresses in
1TB increments, rather than 2TB increments. Crucially, this slowdown
applies to TSan on all platforms, not just RiscV64 48-bit.

This patch slightly shrinks the RiscV64 48-bit LowApp region mapping
(from 5TB to 4TB); we hope that 4TB ought to be enough for anybody,
especially since there is no ASLR applied to the binary in this region.
This allows restoring RestoreAddr to use 3-bits as the indicator again,
thus speeding up TSan on all platforms.

Co-authored-by: Thurston Dang <thurston@google.com>

Make the code clear that nullptrs are not expected.

Fix decl-params-determinisim test after 48be81e1 packed some information
in the clang module. The test is to make sure the decls are appearing in
a strict ordering and it relies on check the correct field in the
bitcode format.

Add more explanation in the comments to help future updates when
serialization format affects this test.

When the top of the instantiation stack is in user code.

The goal of this PR is to allow deprecation of some char_traits
specializations in libc++ as done in https://reviews.llvm.org/D157058
which was later reverted by
https://github.com/llvm/llvm-project/pull/66153#issuecomment-1719578384
as Clang never emitted the libc++ warnings.

Because Clang likes to eagerly instantiate, we can look for the location
of the top of the instantiation stack, and emit a warning if that
location is in user code.

The warning emission is forced by temporarily instructing the diag
engine not to silence warning in system headers.

```
clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp:144:65: warning:
 narrowing conversion of ‘llvm::StringRef(((const char*)"std::experiment
al::filesystem::")).llvm::StringRef::size()’ from ‘size_t’ {aka ‘long un
signed int’} to ‘unsigned int’ [-Wnarrowing]
  144 | #define SYMBOL(Name, NS, Header) {#NS #Name, StringRef(#NS).size
(), #Header},
      |                                              ~~~~~~~~~~~~~~~~~~~
^~
clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc:51:1: note: in ex
pansion of macro ‘SYMBOL’
   51 | SYMBOL(temp_directory_path, std::experimental::filesystem::, <ex
perimental/filesystem>)
      | ^~~~~~
```

Introduce further test exercizing `isAArch64FrameOffsetLegal`.

Adds GraalVM calling conventions. The only difference with the default calling conventions is that GraalVM reserves two registers for the heap base and the thread. Since the registers are then accessed by name, getRegisterByName has to be updated accordingly.

This patch implements the calling conventions only for X86, AArch64 and RISC-V.

For X86, the reserved registers are X14 and X15. For AArch64, they are X27 and X28. For RISC-V, they are X23 and X27.

This patch has been used by the LLVM backend of GraalVM's Native Image project in production for around 4 months with no major issues.

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