Add support for generating a dsymutil reproducer. The result is a folder
containing all the object files for linking.

When --gen-reproducer is passed, dsymutil uses a FileCollectorFileSystem
which keeps track of all the files used by dsymutil. These files are
copied into a temporary directory when dsymutil exists.

When this path is passed to --use-reproducer, dsymutil uses a
RedirectingFileSystem that will use the files from the reproducer
directory instead of the actual paths. This means you don't need to mess
with the OSO path prefix.

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

Reverting this to unblock all the LLDB bots while we try to figure out a
solution for Solaris in https://reviews.llvm.org/D79745.

Still not ideal as the refcounting leaks to users, but better than
before. NFCI.

Summary:
PartialProfileRatio approximately represents the ratio of the number of profile
counters of the program being built to the number of profile counters in the
partial sample profile. It is used to scale the working set size under the
partial sample profile to reflect the size of the program being built and to
improve the working set size heuristics.

This is a split from D79831.

Reviewers: davidxl

Subscribers: eraman, hiraditya, llvm-commits

Tags: #llvm

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

It was set in total vector size while the idea was to limit
a number of instructions. Now it started to work with doubles
and thresholds needs to be updated.

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

This reverts commit fab08bf4.  It has left
the Solaris buildbots broken for a week and a half as reported
in https://reviews.llvm.org/D79745.

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

The algorithm inside getVectorElementSize() is almost O(x^2) complexity and
when, for example, we compile MultiSource/Applications/ClamAV/shared_sha256.c
with 1k instructions inside sha256_transform() function that resulted in almost
~800k iterations. The following change improves the algorithm with the map to
a liner complexity.

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

When moving an instruction into a block where it was referenced by a phi when peeling,
refer to the phi's register number and assert that the instruction has it in its destinations.
This way, it also covers instructions with more than one destination.

Patch by Hendrik Greving!

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

InOMPDeviceContext may be greater than 1. It needs to be clamp to 0 and 1
to be used as index for DoneMap.

Summary:
* Updated ROCDLOps tablegen
* Added parsing and printing function for new intrinsic
* Added unit tests

Reviewers: ftynse

Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, llvm-commits

Tags: #llvm

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

Due to similar APIs between CUDA and ROCm (HIP),
ConvertGpuLaunchFuncToCudaCalls pass could be used on both platforms with some
refactoring.

In this commit:

- Migrate ConvertLaunchFuncToCudaCalls from GPUToCUDA to GPUCommon, and rename.
- Rename runtime wrapper APIs be platform-neutral.
- Let GPU binary annotation attribute be specifiable as a PassOption.
- Naming changes within the implementation and tests.

Subsequent patches would introduce ROCm-specific tests and runtime wrapper
APIs.

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

iAs listed in the summary D77846, we have 5 different categories of bugs we're
checking for in CallAndMessage. I think the documentation placed in the code
explains my thought process behind my decisions quite well.

A non-obvious change I had here is removing the entry for
CallAndMessageUnInitRefArg. In fact, I removed the CheckerNameRef typed field
back in D77845 (it was dead code), so that checker didn't really exist in any
meaningful way anyways.

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

NoDebug attr does not totally eliminate debug info about a function when
inlining is enabled. This is inconsistent with when inlining is disabled.

This patch fixes that.

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

Summary: Compilation with  -DLIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY was failing due to missing declarations of functions used in libcxx/include/atomic. The lines this commit affects are the places where those functions are defined, now moved to be always defined.

Reviewers: #libc, ldionne

Reviewed By: #libc, ldionne

Subscribers: miyuki, dexonsmith, ldionne, jfb, libcxx-commits

Tags: #libc

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

For LLVM on *nix systems, the signal handlers are not run on signals
such as SIGINT due to CTRL-C. See sys::CleanupOnSignal. This makes
sense, as such signals are not really crashes. Prior to this change,
this wasn't the case on Windows, however. This patch changes the Windows
behaviour to be consistent with Linux, and adds testing that verifies
this.

The test uses llvm-symbolizer, but any tool with an interactive mode
would do the job.

Fixes https://bugs.llvm.org/show_bug.cgi?id=45754.

Reviewed by: MaskRay, rnk, aganea

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

Recommitting part of "[CostModel] Unify Intrinsic Costs."
de71def3

Move the switch statement from TTImpl::getIntrinsicCost to
TTI::getIntrinsicInstrCost. This enables BasicTTI to understand
more 'free' intrinsics instead of defaulting to a cost of 1.

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

This reverts commit de71def3.

This is causing some very large changes, so I'm first going to break
this patch down and re-commit in parts.

In case the then-path of an if-region is empty, then merging with the
else-path should be handled with the inverse of the condition (leading
to that path).

Fix PR37662

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

The patch aims to use CallEvents interface in a more principled manner, and also
to highlight what this checker really does. It in fact checks for 5 different
kinds of errors (from checkPreCall, that is):

 * Invalid function pointer related errors
 * Call of methods from an invalid C++ this object
 * Function calls with incorrect amount of parameters
 * Invalid arguments for operator delete
 * Pass of uninitialized values to pass-by-value parameters

In a previous patch I complained that this checker is responsible for emitting
a lot of different diagnostics all under core.CallAndMessage's name, and this
patch shows where we could start to assign different diagnostics to different
entities.

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

We don't need anything specifically from GlobalValue.h

Summary:
Currently, `rewriteLoopExitValues()`'s logic is roughly as following:
> Loop over each incoming value in each PHI node.
> Query whether the SCEV for that incoming value is high-cost.
> Expand the SCEV.
> Perform sanity check (`isValidRewrite()`, D51582)
> Record the info
> Afterwards, see if we can drop the loop given replacements.
> Maybe perform replacements.

The problem is that we interleave SCEV cost checking and expansion.
This is A Problem, because `isHighCostExpansion()` takes special care
to not bill for the expansions that were already expanded, and we can reuse.

While it makes sense in general - if we know that we will expand some SCEV,
all the other SCEV's costs should account for that, which might cause
some of them to become non-high-cost too, and cause chain reaction.

But that isn't what we are doing here. We expand *all* SCEV's, unconditionally.
So every next SCEV's cost will be affected by the already-performed expansions
for previous SCEV's. Even if we are not planning on keeping
some of the expansions we performed.

Worse yet, this current "bonus" depends on the exact PHI node
incoming value processing order. This is completely wrong.

As an example of an issue, see @dmajor's `pr45835.ll` - if we happen to have
a PHI node with two(!) identical high-cost incoming values for the same basic blocks,
we would decide first time around that it is high-cost, expand it,
and immediately decide that it is not high-cost because we have an expansion
that we could reuse (because we expanded it right before, temporarily),
and replace the second incoming value but not the first one;
thus resulting in a broken PHI.

What we instead should do for now, is not perform any expansions
until after we've queried all the costs.

Later, in particular after `isValidRewrite()` is an assertion (D51582)
we could improve upon that, but in a more coherent fashion.

See [[ https://bugs.llvm.org/show_bug.cgi?id=45835 | PR45835 ]]

Reviewers: dmajor, reames, mkazantsev, fhahn, efriedma

Reviewed By: dmajor, mkazantsev

Subscribers: smeenai, nikic, hiraditya, javed.absar, llvm-commits, dmajor

Tags: #llvm

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

This is split off from D80316, slightly tightening the definition of overloaded
hardwareloop intrinsic llvm.loop.decrement.reg specifying that both operands
its result have the same type.

Summary: Also expose some more vector ops to EDSCs.

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

Summary:
I found that because `--system-headers` flag was not included when running clang-tidy, errors produced from compiler provided headers were being suppressed. After passing this flag I realized that by including headers like stdint.h we were indirectly including headers from the system libc. To prevent this we pass `-ffreestanding`.
We don't want to pass `--system-headers` for all checks just the `llvmlibc-restrict-system-libc-headers` therefore we do a separate invocation of clang-tidy for this check.

Reviewers: abrachet, sivachandra

Reviewed By: sivachandra

Subscribers: mgorny, aheejin, tschuett, ecnelises, libc-commits

Tags: #libc-project

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

We do not have any special handling for constant FP deopt arguments.
They are just spilled to stack or generated in register by MOVS
instruction. This is inefficient and, when we have too many such
constant arguments, may result in register allocation failure.
Instead, we can bitcast such constant FP operands to appropriately
sized integer and record as constant into statepoint and later, into
StackMap.

Reviewed By: skatkov
Differential Revision: https://reviews.llvm.org/D80318

NFC.

getField() may return a nullptr, we already did that in
BodyIndexer::VisitDesignatedInitExpr, but missed one place.