Not removing the malloc from earliest escape info leaves stale entries
in the cache.

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

PR: https://github.com/llvm/llvm-project/pull/84157

After 3ecd38c8, the Handler.getELFObjectFile routine is no
longer available.  Call ELF64LEObjectFile::create directly,
which should always be suitable for CUDA images.

The plugin was not getting built as the build_generic_elf64 macro
assumes the LLVM triple processor name matches the CMake processor name,
which is unfortunately not the case for SystemZ.

Fix this by providing two separate arguments instead.

Actually building the plugin exposed a number of other issues causing
various test failures. Specifically, I've had to add the SystemZ target
to
- CompilerInvocation::ParseLangArgs
- linkDevice in ClangLinuxWrapper.cpp
- OMPContext::OMPContext (to set the device_kind_cpu trait)
- LIBOMPTARGET_ALL_TARGETS in libomptarget/CMakeLists.txt
- a check_plugin_target call in libomptarget/src/CMakeLists.txt

Finally, I've had to set a number of test cases to UNSUPPORTED on
s390x-ibm-linux-gnu; all these tests were already marked as UNSUPPORTED
for x86_64-pc-linux-gnu and aarch64-unknown-linux-gnu and are failing on
s390x for what seem to be the same reason.

In addition, this also requires support for BE ELF files in
plugins-nextgen: https://github.com/llvm/llvm-project/pull/83976

Code in plugins-nextgen reading ELF files is currently hard-coded to
assume a 64-bit little-endian ELF format. Unfortunately, this assumption
is even embedded in the interface between GlobalHandler and Utils/ELF
routines, which use ELF64LE types.

To fix this, I've refactored the interface to push all ELF specific
types into Utils/ELF. Specifically, this patch removes both the
getSymbol and getSymbolAddress routines and replaces them with a
single findSymbolInImage, which gets a StringRef identifying the
raw object file image as input, and returns a StringRef covering
the data addressed by the symbol (address and size) if found, or
std::nullopt otherwise.

This allows properly templating over multiple ELF format variants inside
Utils/ELF; specifically, this patch adds support for 64-bit big-endian
ELF files in addition to 64-bit little-endian files.

The full fold is one of the following:
1) `(fp_binop ({s|u}itofp x), ({s|u}itofp y))`
    -> `({s|u}itofp (int_binop x, y))`
2) `(fp_binop ({s|u}itofp x), FpC)`
    -> `({s|u}itofp (int_binop x, (fpto{s|u}i FpC)))`

And support the following binops:
    `fmul` -> `mul`
    `fadd` -> `add`
    `fsub` -> `sub`

Proofs: https://alive2.llvm.org/ce/z/zuacA8

The proofs timeout, so they must be reproduced locally.

Closes #82555

Just a simple compile time improvement. This function isn't used much,
however, so its not particularly impactful.

Closes #83638

[CLANG][DWARF] Do not emit -ggnu-pubnames for LLDB tuning, unless -ggnu-pubnames is specified. (#83331)

When -gsplit-dwarf is passed in clang emmmits -ggnu-pubnames which
results in
.debug_gnu_pubnames/..debug_gnu_pubtypes being generated.
This is used by GDB, but not by LLDB.
Changed so that these sections are not emitted for LLDB tuning, unless
flag
is passed explicitly.

With out-of-process execution the target triple can be different from
the one on the host. We need an interface to configure it.

TestAddressMasks failed on the lldb-arm-buntu bot with the
Code address mask test,

        mask = process.GetAddressMask(lldb.eAddressMaskTypeAny)
        process.SetAddressMask(lldb.eAddressMaskTypeCode, mask | 0x3)
        self.assertEqual(
            0x000002950001F694,
            process.FixAddress(0x00265E950001F697, lldb.eAddressMaskTypeCode),
        )

The API returned 0x000002950001f694 instead of the expected
0x00265e950001f696.  The low bits differ because ABISysV_arm hardcodes
the Code address mask to clear the 0th bit, it doesn't use the
Process code mask.  I didn't debug why some of the high bytes were
dropped.  The address mask APIs are only important on 64-bit targets,
where many of the bits are not used for addressing and are used for
metadata instead, so I'm going to skip these tests on 32-bit arm
instead of debugging.

We got user reporting lldb crash while the debuggee is calling vfork()
concurrently from multiple threads.
The crash happens because the current implementation can only handle
single vfork, vforkdone protocol transaction.

This diff fixes the crash by lldb-server storing forked debuggee's <pid,
tid> pair in jstopinfo which will be decoded by lldb client to create
StopInfoVFork for follow parent/child policy. Each StopInfoVFork will
later have a corresponding vforkdone packet. So the patch also changes
the `m_vfork_in_progress` to be reference counting based.

Two new test cases are added which crash/assert without the changes in
this patch.

---------

Co-authored-by: jeffreytan81 <jeffreytan@fb.com>

/usr/bin/ld: CMakeFiles/RISCVTests.dir/RISCVInstrInfoTest.cpp.o: undefined
reference to symbol '_ZNK4llvm12LocationSize5printERNS_11raw_ostreamE'
/usr/bin/ld: /work/kparzysz/git/llvm.org/b/x86/lib/libLLVMAnalysis.so.19.0
git: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

The undefined symbol is
llvm::LocationSize::print(llvm::raw_ostream&) const

When printing the result of SCEV's analysis, we can avoid printing
the predicated backedge taken count and the predicates if the predicates
are empty and no new information is provided.  This helps to reduce the
verbosity of the output.

This is just code refactoring done as a preparation for adding
MLIR inliner cost model hook(s).
Related discussion: https://discourse.llvm.org/t/inliner-cost-model/2992

The logic of SCC-based MLIR inliner is separated into the Inliner
implementation. The MLIR inliner pass becomes, well, just a pass
that invokes the SCC-based MLIR inliner.

[lldb] Add SBProcess methods for get/set/use address masks (#83095)

I'm reviving a patch from phabracator, https://reviews.llvm.org/D155905
which was approved but I wasn't thrilled with all the API I was adding
to SBProcess for all of the address mask types / memory regions. In this
update, I added enums to control type address mask type (code, data,
any) and address space specifiers (low, high, all) with defaulted
arguments for the most common case.  I originally landed this via
https://github.com/llvm/llvm-project/pull/83095 but it failed on CIs
outside of arm64 Darwin so I had to debug it on more environments
and update the patch.

This patch is also fixing a bug in the "addressable bits to address
mask" calculation I added in AddressableBits::SetProcessMasks. If lldb
were told that 64 bits are valid for addressing, this method would
overflow the calculation and set an invalid mask. Added tests to check
this specific bug while I was adding these APIs.

This patch changes the value of "no mask set" from 0 to
LLDB_INVALID_ADDRESS_MASK, which is UINT64_MAX. A mask of all 1's
means "no bits are used for addressing" which is an impossible mask,
whereas a mask of 0 means "all bits are used for addressing" which
is possible.

I added a base class implementation of ABI::FixCodeAddress and
ABI::FixDataAddress that will apply the Process mask values if they
are set to a value other than LLDB_INVALID_ADDRESS_MASK.

I updated all the callers/users of the Mask methods which were
handling a value of 0 to mean invalid mask to use
LLDB_INVALID_ADDRESS_MASK.

I added code to the all AArch64 ABI Fix* methods to apply the
Highmem masks if they have been set.  These will not be set on a
Linux environment, but in TestAddressMasks.py I test the highmem
masks feature for any AArch64 target, so all AArch64 ABI  plugins 
must handle it.

rdar://123530562

Co-authored-by: Jon Roelofs <jroelofs@gmail.com>

…rage layout.

Use a path that works for both standalone as well as full repository
builds.

Fixes: 9b672de9 ("[clang][Builtins] Parse clang extended vectors types. (#83584)")

This is another part of #70452 which makes getMemOperandsWithOffsetWidth
use a LocationSize for Width, as opposed to the unsigned it currently
uses. The advantages on it's own are not super high if
getMemOperandsWithOffsetWidth usually uses known sizes, but if the
values can come from an MMO it can help be more accurate in case they
are Unknown (and in the future, scalable).

Remove the `default` label from a switch that covers all cases.

This reverts commit deff460b.

Committed this from a different computer with my old (invalid) email
address.

Remove the `default` label from a switch that covers all cases.

Don't just return the known zero upperbits, compute the absdiff Knownbits and perform the horizontal sum.

Add implementations that handle both the X86ISD::PSADBW nodes and the INTRINSIC_WO_CHAIN intrinsics (pre-legalization).

There is a small chance that binary id starting with 0 (1/256). It is
not sufficient to just check the first byte.

This patch handles the pattern `icmp pred (trunc X), C` in
`computeKnownBitsFromCmp` to infer low bits of `X` from dominating
conditions.

Summary:
After the overhaul of the GPU build the documentation pages were a
little stale. This updates them with more in-depth information on
building the GPU runtimes and using them. Specifically using them goes
through the differences between the offloading and direct compilation
modes.

Instead of initializing the accumulator to 0. Initialize it on first
assignment with a mv from the register that holds VLENB << ShiftAmount.

Fix a missing kill flag on the final Add.

I have no real interest in this case, just an easy optimization I
noticed.

When printing the result of the analysis, i8 -1 and i64 -1 are quite
different in terms of analysis quality.  In a recent conversion with
a new contributor, we ran into exactly this confusion.

Adding the type for constant scevs more globally seems worthwhile, but
introduces a much larger test diff.  I'm splitting this off first since
it addresses the immediate need, and then going to do some further
changes to clarify a few related bits of analysis result output.

Add members "leafConstructs" and "association" to .td describing
OpenMP/ACC directives. The naming follows the terminology used in the
OpenMP standard: a "leaf" construct is a construct that is itself not a
composition or a combination of other constructs, and "association" is
the source language construct to which the directive applies (e.g. loop,
block, etc.)

The tblgen-generated output then contains two additional functions
- getLeafConstructs(D), and
- getDirectiveAssociation(D)
plus "enum class Association", all in namespaces "llvm::omp" and
"llvm::acc".

Note: getLeafConstructs returns an empty sequence for a construct that
is itself a leaf construct.

Use the new functions to simplify a few OpenMP-related functions in
clang.

This is similar to #83017 but for the areas in GlobalISel's
LoadStoreOpt, and should help simplify #70452 a little. It will likely
change a little again once the sizes can be scalable.

Signed-off-by: nwh <nwh_work@foxmail.com>

Fixes #78810 
Thanks for Snape3058 's comment

---------

Co-authored-by: miaozhiyuan <miaozhiyuan@feysh.com>

There are code bases that inline `std::move` manually via `static_cast`.
Treat a static cast to an xvalue as an inlined `std::move` call and warn
on a self move.

For example for unknown parameter decls.