The devirtualization wrapper misses cases where if it wraps a pass
manager, an individual pass may devirtualize an indirect call created by
a previous pass. For example, inlining may create a new indirect call
which is devirtualized by instcombine. Currently the devirtualization
wrapper will not see that because it only checks cgscc edges at the very
beginning and end of the pass (manager) it wraps.

This fixes some tests testing this exact behavior in the legacy PM.

Instead of checking WeakTrackingVHs for CallBases at the very beginning
and end of the pass it wraps, check every time
updateCGAndAnalysisManagerForPass() is called.

check-llvm and check-clang with -abort-on-max-devirt-iterations-reached
on by default doesn't show any failures outside of tests specifically
testing it so it doesn't needlessly rerun passes more than necessary.
(The NPM -O2/3 pipeline run the inliner/function simplification pipeline
under a devirtualization repeater pass up to 4 times by default).

http://llvm-compile-time-tracker.com/?config=O3&stat=instructions&remote=aeubanks
shows that 7zip has ~1% compile time regression. I looked at it and saw
that there indeed was devirtualization happening that was not previously
caught, so now it reruns the CGSCC pipeline on some SCCs, which is WAI.

The initial land assumed CallBase WeakTrackingVHs would always be
CallBases, but they can be RAUW'd with undef.

Reviewed By: asbirlea

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

The legacy pass didn't properly detect indirect calls.

We can still remove the convergent attribute when there are indirect
calls. The LangRef says:

> When it appears on a call/invoke, the convergent attribute indicates
that we should treat the call as though we’re calling a convergent
function. This is particularly useful on indirect calls; without this we
may treat such calls as though the target is non-convergent.

So don't skip handling of convergent when there are unknown calls.

Reviewed By: jdoerfert

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

Minor code refactor to improve readability.

This fixes the Builtins-sparc-linux testsuite failures on Linux
SPARC which occur because clang cannot find the 32-bit runtime
libraries when -m32 is passed on the command line. The same
workaround is already being used on X86 and PPC.

Also, switch the CHECK-DEBIAN-SPARC tests to use debian_multiarch_tree
as both sparc and sparc64 are using the MultiArch mechanism on modern Debian
systems the same way as x86_64, powerpc64el and others. Thus, switch the
CHECK-DEBIAN-SPARC32 and CHECK-DEBIAN-SPARC64 tests to use the files from
the debian_multiarch_tree directory for the header and linker path tests.

Finally, rename CHECK-DEBIAN-SPARC32 to CHECK-DEBIAN-SPARC to match the naming
scheme of the Debian MultiArch checks for the other Debian architectures.

Reviewed By: MaskRay, phosek

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

* Remove misnamed `PPC64_HAS_VMX` in preference of directly checking `defined(__VSX__)`.

libunwind was using "VMX" to mean "VSX". "VMX" is just another name for Altivec, while "VSX" is the vector-scalar extensions first used in POWER7. Exposing a "PPC64_HAS_VMX" define was misleading and incorrect.

* Add `defined(__ALTIVEC__)` guards around vector register operations to fix non-altivec CPUS such as the e5500.

When compiling for certain Book-E processors such as the e5500, we want to skip vector save/restore, as the Altivec registers are illegal on non-Altivec implementations.

* Add `!defined(__NO_FPRS__)` guards around traditional floating-point save/restore.

When compiling for powerpcspe, we cannot access floating point registers, as there aren't any. (The SPE on e500v2 is a 64-bit extension of the GPRs, and it doesn't have the normal floating-point registers at all.)
This fixes building for powerpcspe, although no actual handling for SPE save/rest...

llvm-config output with the gn build is just good enough to make
tests pass, but llvm-config wants all .a files it knows about to
actually exist. So let it know about fewer .a files that don't
exist if not all targets are enabled.

This patch fixes a minor typo in RegisterContextPOSIXProcessMonitor_arm64
constructor where memset target was wrongly specified as m_fpr instead of
m_gpr_arm64.

Extend TestProcessConnect to cover the scenario fixed by
6c0cd567. This replaces
command-process-connect.test which would fail if port 4321
was open.

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

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

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

Support for outgoing calls is left for a future change.

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

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

Similar to fsub, fdiv can also be vectorized using fmul.

Also http://llvm.org/viewvc/llvm-project?view=revision&revision=215200

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



Co-authored-by: Jameson Nash <jameson@juliacomputing.com>

Ensure that the DSO Locality of the globals in the IR is derived from
their final visibility when using -fvisibility-from-dllstorageclass.

To accomplish this we reset the DSO locality of globals (before
setting their visibility from their dllstorageclass) at the end of
IRGen in Clang. This removes any effects that visibility options or
annotations may have had on the DSO locality.

The resulting DSO locality of the globals will be pessimistic
w.r.t. to the normal compiler IRGen.

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

Breaks some asan tests on the buildbot.

This reverts commit c74b427c.

Remove an invalid check from sizes.cpp that only passes when overcommit is disabled.

Fixes PR48274.

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

llvm-symbolizer used to use the DIA SDK for symbolization on
Windows; this patch switches to using native symbolization, which was
implemented recently.

Users can still make the symbolizer use DIA by adding the `-dia` flag
in the LLVM_SYMBOLIZER_OPTS environment variable.

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

A uniform load is one which loads from a uniform address across all lanes. As currently implemented, we cost model such loads as if we did a single scalar load + a broadcast, but the actual lowering replicates the load once per lane.

This change tweaks the lowering to use the REPLICATE strategy by marking such loads (and the computation leading to their memory operand) as uniform after vectorization. This is a useful change in itself, but it's real purpose is to pave the way for a following change which will generalize our uniformity logic.

In review discussion, there was an issue raised with coupling cost modeling with the lowering strategy for uniform inputs.  The discussion on that item remains unsettled and is pending larger architectural discussion.  We decided to move forward with this patch as is, and revise as warranted once the bigger picture design questions are settled.

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

It is a simple conversion that only requires to change the region argument
types, generalize it from ParallelOp.

Reviewed By: kiranchandramohan

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

Fixes LWG issue 2724: "The protected virtual member functions of memory_resource should be private."

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

Nothing references this class today so it looks like some leftover.

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

While this makes the unit tests a bit more verbose, this simplifies the creation of bindings because only the bidirectional mapping between the host language's string type and MlirStringRef need to be implemented.

Reviewed By: mehdi_amini

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

This is a retry of 324a5320. I cautiously reverted that at 6aa3fc4a
because the rules about gep math were not clear. Since then, we
have added this line to LangRef for gep inbounds:
"The successive addition of offsets (without adding the base address)
does not wrap the pointer index type in a signed sense (nsw)."

See D90708 and post-commit comments on the revert patch for more details.

This adds internal representation of the attributes in a more usable
form.  This is meant to allow programmatic access to the attributes that
are specified in the YAML data.

This is based upon the work contributed by Apple at
https://github.com/llvm/llvm-project-staging/tree/staging/swift/apinotes.

Differential Revision: https://reviews.llvm.org/D91104
Reviewed By: Gabor Marton

This reverts commit 14a68b4a.

Causes building self hosted clang to crash when using NPM.

This reapplies 36c64af9 in updated
form.

Emit the xdata for each function at .seh_endproc. This keeps the
exact same output header order for most code generated by the LLVM
CodeGen layer. (Sections still change order for code built from
assembly where functions lack an explicit .seh_handlerdata
directive, and functions with chained unwind info.)

The practical effect should be that assembly output lacks
superfluous ".seh_handlerdata; .text" pairs at the end of functions
that don't handle exceptions, which allows such functions to use
the AArch64 packed unwind format again.

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

We should share options when possible.

Reviewed By: asbirlea

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

This test is flaky because it assumes port 4321 is not already open on a machine.

Current check compiles the regex on every attempt at matching. The check also populates and enables a regex value by default so the default behaviour results in regex re-compilation for every macro - if the check is enabled. If people used this check there's a reasonable chance they would have relatively complex regexes in use.

This is a quick and simple fix to store and use the compiled regex.

Reviewed By: njames93

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

Fixes a recently added test that has this dependency. IMO this utility
is generally useful, so we should go ahead and take the new dependency.

This change serves to create the initial framework for outputting ELF
files from llvm-elfabi.

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

Addresses https://bugs.llvm.org/show_bug.cgi?id=48230.
Handle the case when the Fixup suggested isn't a valid c/c++ identifer.

Reviewed By: aaron.ballman, gribozavr2

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