distutils is deprecated and shutil.which is the suggested
replacement for this function.

https://peps.python.org/pep-0632/#migration-advice
https://docs.python.org/3/library/shutil.html#shutil.which

It was added in Python3.3 but given that we're already using
shutil.which elsewhere I think this is ok/no worse than before.

We do have our own find_executable in lldb/test/Shell/helper/build.py
but I'd rather leave that as is for now. Also we have our own versions
of which() but again, a change for another time.

This work is part of #54337.

Reviewed By: JDevlieghere

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

I think this sort comparator was overly complex, and the windows
expensive check bot agreed, failing as it was not giving a strict weak
ordering. Change it to use the comparison of the mask values as unsigned
integers. This should sort the undef elements to the end whilst keeping
X<Y otherwise.

Replace the condition value with the known constant value on the
threaded edge. This happens implicitly with phi threading because
we replace with the incoming value, but not for non-phi threading.

Test depends on pthread_cancel which is not supported on Android.

SimplifyCFG implements basic jump threading, if a branch is
performed on a phi node with constant operands. However,
InstCombine canonicalizes such phis to the condition value of a
previous branch, if possible. SimplifyCFG does support this as
well, but only in the very limited case where the same condition
is used in a direct predecessor -- notably, this does not include
the common diamond pattern (i.e. two consecutive if/elses on the
same condition).

This patch extends the code to look back a limited number of
blocks to find a branch on the same value, rather than only
looking at the direct predecessor.

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

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

When assertions are enabled, clang will perform RoundTrip for CompilerInvocation argument generation. ibt-seal flags are currently missing in this argument generation, and because of that, the feature doesn't get enabled for these cases. Performing RoundTrip is the default for assert builds, rendering the feature broken in these scenarios.

This patch fixes this and adds a test to properly verify that modules are  being generated with the flag when -mibt-seal is used.

Please, add any known relevant reviewer which I may have missed.

[1] - https://reviews.llvm.org/D116070

Reviewed By: pengfei, gftg, aaron.ballman, nickdesaulniers

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

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

Add cost model for broadcast shuffle in RISCVTTIImpl::getShuffleCost
with scalable vector. The cost model might not the best.

For scalable vector, BasicTTIImpl::getShuffleCost return invalid cost,
so this patch relies on the existing cost model in BasicTTIImpl.

Reviewed By: craig.topper

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

Thanks for @rsmith to point this. I'm sorry for introducing this bug.
See @rsmith 's comment in https://reviews.llvm.org/D122248
Eg:(By @rsmith ) https://godbolt.org/z/o7vcbWaEf
I have added a test case
struct:
```
struct U19A {
    int a;
  };
  struct U19B {
    struct U19A a;
  };

  struct U19B a = {
    .a.a = 2022
  };
```
Dump result:
```
struct U19B {
    struct U19A a = {
        int a = 2022
    }
}
```

Reviewed By: erichkeane

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

This patch adds peephole optimizations for the following patterns:

(load (add base, (addi src, off1)), off2)
   -> (load (add base, src), off1+off2)
(store val, (add base, (addi src, off1)), off2)
   -> (store val, (add base, src), off1+off2)

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

PowerPC supports `ppc_fp128`, which is not an IEEE floating point
type. The generic lowering of llvm.is_fpclass could not handle it
properly. This change extends the generic lowering code to
support `ppc_fp128`.

The change was tested on emulator using runtime tests from
https://reviews.llvm.org/D112933 and the patch for clang
https://reviews.llvm.org/D112932.

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

By default -fsanitize=address already compiles with this check, why not use it.
For compatibly it can be disabled with env ASAN_OPTIONS=detect_stack_use_after_return=0.

Reviewed By: eugenis, kda, #sanitizers, hans

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

The goal of this patch is to improve distribution build's flexibility to include only applicable header files.

Currently, the clang-resource-headers target contains nearly all the files in clang/lib/Headers. Most of these files are platform specific (e.g. immintrin.h is x86 specific). A distribution build will have to either include all the headers for all the platforms, or not include any headers. For example, if a distribution build for powerpc includes the clang-resource-headers target, it will include all the x86 specific headers, even-though the x86 specific headers cannot be used.

This patch breaks up the clang-resource-headers list to a core list and platform specific lists. With the patch, a distribution build can now include the ppc-resource-headers to include the headers applicable to the powerpc platform.

Specifically, one can now have

cmake ... LLVM_DISTRIBUTION_COMPONENTS="clang;ppc-resource-headers" ... ../llvm
ninja install-distribution then installs the powerpc headers.

Similarly, one can do

cmake ... LLVM_DISTRIBUTION_COMPONENTS="clang;x86-resource-headers" ... ../llvm
to include headers applicable to the x86 platform in a distribution installation.

To implement this behaviour, the patch does two things

It breaks up the long files header file list to a core list and platform specific lists.
It adds numerous platform specific installation targets.

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

[CMake] Ensure correct extension for llvm-lit is used on Windows when LLVM_INSTALL_UTILS is enabled.

D77110 initially added support for setting LLVM_CONFIG_DEFAULT_EXTERNAL_LIT
to llvm-lit in the install directory if LLVM_INSTALL_UTILS is on.

D79144 ensured that, on Windows, llvm-lit.py is correctly set for
LLVM_CONFIG_DEFAULT_EXTERNAL_LIT within the context of the build area,
however, it did not account for the install area which is the latter set
directive for this same variable.

This patch ensures that LLVM_CONFIG_DEFAULT_EXTERNAL_LIT under the install
area uses llvm-lit.py under Windows since llvm-lit without the extension
is not created.

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

Prevents confusion over which `S` is referenced in the final `else`
branch if such use is added.

Reviewed By: hubert.reinterpretcast

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

We are considering to make -fsanitize-memory-param-retval enabled by default so probably this patch is unnneded.

Reviewed By: #libc, EricWF

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

Delete the output streams coming from
CompilerInstance::createOutputFile() and friends once writes are
finished. Concretely, replacing `OS->flush()` with `OS.reset()` in:

- `ExtractAPIAction::EndSourceFileAction()`
- `PrecompiledPreambleAction::setEmittedPreamblePCH()`
- `cc1_main()'s support for `-ftime-trace`

This fixes theoretical bugs related to proxy streams, which may have
cleanups to run in their destructor. For example, a proxy that
CompilerInstance sometimes uses is `buffer_ostream`, which wraps a
`raw_ostream` lacking pwrite support and adds it. `flush()` does not
promise that output is complete; `buffer_ostream` needs to wait until
the destructor to forward anything so that it can service later calls to
`pwrite()`. If the destructor isn't called then the proxied stream
hasn't received any content.

This also protects against some logic bugs, triggering a null
dereference on a later attempt to write to the stream.

No test...

The patch is straightforward except the tiny fix in BugReporterVisitors.cpp
that suppresses a default note for "Assuming pointer value is null" when
a note tag from the checker is present. This is probably the right thing to do
but also definitely not a complete solution to the problem of different sources
of path notes being unaware of each other, which is a large and annoying issue
that we have to deal with. Note tags really help there because they're nicely
introspectable. The problem is demonstrated by the newly added getenv() test.

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

MSVC and Itanium mangling use different mangling numbers
for function-scope structs, which causes inconsistent
mangled kernel names in device and host compilations.

This patch uses Itanium mangling number for structs
in for mangling device side names in CUDA/HIP host
compilation on Windows to fix this issue.

A state is added to ASTContext to indicate whether the
current name mangling is for device side names in host
compilation. Device and host mangling number
are encoded/decoded as upper and lower half of 32 bit
unsigned integer to fit into the original mangling number
field for AST. Diagnostic will be emitted if a manglining
number exceeds limit.

Reviewed by: Artem Belevich, Reid Kleckner

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

Fixes: SWDEV-328515

[NFC][SCEV] Refactor `createNodeForSelectViaUMinSeq()` out of `createNodeForSelectOrPHIViaUMinSeq()`

This reverts commit a15b66e7.

This causes linker to crash at assertion: `Assertion failed: !Expr->isComplex(), file C:\b\s\w\ir\cache\builder\src\third_party\llvm\llvm\lib\CodeGen\LiveDebugValues\InstrRefBasedImpl.cpp, line 907`.

This patch is fixing two issues for both CS and non-CS.
1) For external-call-internal, the head samples of the the internal function should be recorded.
2) avoid ignoring LBR after meeting the interrupt branch for CS profile

LBR parser is shared between CS and non-CS, we found it's error-prone while dealing with artificial branch inside LBR parser. Since artificial branch is mainly used for CS profile unwinding, this patch tries to simplify LBR parser by decoupling artificial branch code from it, the concept of artificial branch is removed and split into two transitional branches(internal-to-external, external-to-internal). Then we leave all the processing of external branch to unwinder.

Specifically for unwinder, remembering that we introduce external frame in https://reviews.llvm.org/D115550. We can just take external address as a regular address and reuse current unwind function(unwindCall, unwindReturn). For a normal case, the external frame will match an external LBR, and it will be filtered out by `unwindLinear` without losing any context.

The data also shows that the interrupt or standalone LBR pattern(unpaired case) does exist, we choose to handle it by clearing the call stack and keeping unwinding. Here we leverage checking in `unwindLinear`, because a standalone LBR, no matter its type, since it doesn’t have other part to pair, it will eventually cause a wrong linear range, like [external, internal], [internal, external]. Then set the state to invalid there.

Reviewed By: hoy, wenlei

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

These tests are timing out on the bots.

[Tooling/DependencyScanning] Make skipping excluded PP ranges during dependency scanning the default

This is to improve maintenance a bit and remove need to maintain the additional option and related code-paths.

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

The goal in 75881d8b was just modifying what `Result` is, didn't
need to also modify ::run.

This patch fixes a crash when using process launch -t to launch the
inferior from a TTY. The issue is that on Darwin, Host.mm is calling
ConnectionFileDescriptor::Connect without a socket_id_callback_type. The
overload passes nullptr as the function ref, which gets called
unconditionally as the socket_id_callback.

One potential way to fix this is to change all the lambdas to include a
null check, but instead I went with an empty lambda.

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

Since D110065, the 'R' profile support is added to LLVM. It turns the
`generic` cpu into the intersection of v8-a and v8-r. However, this
makes some backward compatibility problems. The original patch makes
the clang driver implicitly pass -march=armv8-a when only the triple
is specified. Since it only applies to clang, other tools like
llvm-objdump still faces the backward compatibility problem.

This patch applies the same idea to MC related tools by enabling '+v8a'
feature when nothing is specified (both CPU and FS are empty) for
MCSubtargetInfo creation.

This patch should fix PR53956.

Reviewed by: labrinea

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

The relocation value is calculated using the formula S + A - P,
the verification of the value is performed by inversely calculating the location address

Reviewed By: Amir

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

In case of interrupting, there were None. Fixes PR55176.

This reverts commit 28d09bbb
while I investigate a buildbot failure.

With BMI2 we have SHRX which is a lot quicker than regular x86 shifts.

Fixes #55138

Add extra check-prefixes to merge common results.

This patch permits Swing Modulo Scheduling for ARM targets
turns it on by default for the Cortex-M7.  The t2Bcc
instruction is recognized as a loop-ending branch.

MachinePipeliner is extended by adding support for
"unpipelineable" instructions.  These instructions are
those which contribute to the loop exit test; in the SMS
papers they are removed before creating the dependence graph
and then inserted into the final schedule of the kernel and
prologues. Support for these instructions was not previously
necessary because current targets supporting SMS have only
supported it for hardware loop branches, which have no
loop-exit-contributing instructions in the loop body.

The current structure of the MachinePipeliner makes it difficult
to remove/exclude these instructions from the dependence graph.
Therefore, this patch leaves them in the graph, but adds a
"normalization" method which moves them in the schedule to
stage 0, which causes them to appear properly in kernel and
prologues.

It was also necessary to be more careful about boundary nodes
when iterating across successors in the dependence graph because
the loop exit branch is now a non-artificial successor to
instructions in the graph. In additional, schedules with physical
use/def pairs in the same cycle should be treated as creating an
invalid schedule because the scheduling logic doesn't respect
physical register dependence once scheduled to the same cycle.

Reviewed By: dmgreen

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

We weren't properly returning the result of the constraint,
which leads to errors when actually trying to use the generated
C++.

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

We currently aren't handling this properly, and in the case
of a string block just crash. This commit adds proper error handling
and detection for eof.

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

SourceMgr generally uses 1-based locations, whereas the LSP is zero based.
This commit corrects this conversion and also enhances the conversion from SMLoc
to SMRange to support string tokens.

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

We currently emit an error during verification if a pdl.operation with non-inferrable
results is used within a rewrite. This allows for catching some errors during compile
time, but is slightly broken. For one, the verification at the PDL level assumes that
all dialects have been loaded, which is true at run time, but may not be true when
the PDL is generated (such as via PDLL). This commit fixes this by not emitting the
error if the operation isn't registered, i.e. it uses the `mightHave` variant of trait/interface
methods.

Secondly, we currently don't verify when a pdl.operation has no explicit results, but the
operation being created is known to expect at least one. This commit adds a heuristic
error to detect these cases when possible and fail. We can't always capture when the user
made an error, but we can capture the most common case where the user expected an
operation to infer its result types (when it actually isn't possible).

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