A status page for libc++'s Format library. The page is inspired by
@zoecarver's Ranges status page.

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

When I added this assert in D93609, it asserted that a symbol that
is privateExtern is also isExternal().

In D98381 the privateExtern check moved into shouldExportSymbol()
but the assert didn't -- now it checked that _every_ non-exported
symbol is isExternal(), which isn't true. Move the assert into the
privateExtern check where it used to be.

Fixes PR50098.

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

Reviewed By: #libc, ldionne, Quuxplusone, Mordante

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

This clang-formats the list of ARMISD nodes. Usually this is something I
would avoid, but these cause problems with formatting every time new
nodes are added.

The list in getTargetNodeName also makes use of MAKE_CASE macros, as
other backends do.

Taken mostly from LLVM langref.

- the macro seems needlessly clever -- shorter and imho clearer without it
- give all filenames an extension so they look like filenames
- rename .private_extern symbol from _private to _private_extern
  to prepare for follow-up that adds a truly private symbol

No behavior change.

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

Would've caught the (since fixed) regression in D97610.

No behavior change.

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

Use offsets stored in `AliasResult` implemented in D98718.

Reviewed By: nikic

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

We previously had a different interpretation of unroll transformation
attributes than how LoopUnroll interpreted it. In particular,
llvm.loop.unroll.enable was needed explicitly to enable it and disabling
metadata was ignored.
Additionally, it required that either full unrolling or an unroll factor
to be specified or fail otherwise. An unroll factor is still required,
but the transformation is ignored with the hope that LoopUnroll is going
to apply the unrolling, since Polly currently does not implement an
heuristic.

Fixes llvm.org/PR50109

Enable reporting fork/vfork events to the server when supported.
At this moment, this is used only to test the server code, as real
client does not report fork-events and vfork-events as supported.

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

Add a NativeDelegate API to pass new processes (forks) to LLGS,
and support detaching them via the 'D' packet.  A 'D' packet without
a specific PID detaches all processes, otherwise it detaches either
the specified subprocess or the main process, depending on the passed
PID.

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

Introduce three new stop reasons for fork, vfork and vforkdone events.
This includes server support for serializing fork/vfork events into
gdb-remote protocol.  The stop infos for the two base events take a pair
of PID and TID for the newly forked process.

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

Introduce a NativeProcessProtocol API for indicating support for
protocol extensions and enabling them.  LLGS calls
GetSupportedExtensions() method on the process factory to determine
which extensions are supported by the plugin.  If the future is both
supported by the plugin and reported as supported by the client, LLGS
enables it and reports to the client as supported by the server.

The extension is enabled on the process instance by calling
SetEnabledExtensions() method.  This is done after qSupported exchange
(if the debugger is attached to any process), as well as after launching
or attaching to a new inferior.

The patch adds 'fork' extension corresponding to 'fork-events+'
qSupported feature and 'vfork' extension for 'vfork-events+'.  Both
features rely on 'multiprocess+' being supported as well.

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

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

Lowering gather operation to linalg dialect.

Reviewed By: rsuderman

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

Implements parts of:
    * P0896R4 The One Ranges Proposal`

Depends on D100073.

Reviewed By: ldionne, zoecarver, #libc

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

Some builders failed with a missing clang dependency. E.g.

CMake Error at /Users/buildslave/jenkins/workspace/clang-stage1-RA/clang-build \
  /lib/cmake/llvm/AddLLVM.cmake:1786 (add_dependencies):
The dependency target "clang" of target "check-compiler-rt" does not exist.

Reverting while I investigate.

This reverts commit 1e1d75b1.

This patch contains initial directories and build files for the ORC runtime.

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

[libomptarget] Enable AMDGPU devicertl

The amdgpu devicertl is written in freestanding openmp and compiles to a
bitcode library (per listed gfx arch) with no unresolved symbols. It requires
a recent clang, preferably the one from the same monorepo checkout.

This is D98658, with printf explicitly stubbed out, after patching clang to no
longer require an llvm with the amdgpu target enabled.

Reviewed By: tianshilei1992

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

clang-cl doesn't properly handle concepts right now and is failing CI.

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

The data member 'shouldEmitMoves' is only used in DwarfCFIException::beginFunction()
and 'shouldEmitCFI' in DwarfCFIExceptionBase serves its purpose.

Reviewed By: MaskRay

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

Use getContainerForFixedLengthVector and getRegClassIDForVecVT to
get the register class to use when making a fixed vector type legal.

Inline it into the other two call sites.

I'm looking into using fractional lmul for fixed length vectors
and getLMULForFixedLengthVector returned an integer making it
unable to express this. I considered returning the LMUL
enum, but that seemed like it would introduce more complexity to
convert it for use.

At the moment, MachineCSE allows CSE-ing convergent instrs which are
non-local to each other. This can cause illegal codegen as convergent
instrs are control flow dependent. The patch prevents non-local CSE of
convergent instrs by adding a check in isProfitableToCSE and rejecting
CSE-ing if we're considering CSE-ing non-local convergent instrs. We
can still CSE convergent instrs which are in the same control flow
scope, so the patch purposely does not make all convergent instrs
non-CSE candidates in isCSECandidate.

https://reviews.llvm.org/D101187

[clang][amdgpu] Use implicit code object version

At present, clang always passes amdhsa-code-object-version on to -cc1. That is
great for certainty over what object version is being used when debugging.

Unfortunately, the command line argument is in AMDGPUBaseInfo.cpp in the amdgpu
target. If clang is used with an llvm compiled with DLLVM_TARGETS_TO_BUILD
that excludes amdgpu, this will be diagnosed (as discovered via D98658):

- Unknown command line argument '--amdhsa-code-object-version=4'

This means that clang, built only for X86, can be used to compile the nvptx
devicertl for openmp but not the amdgpu one. That would shortly spawn fragile
logic in the devicertl cmake to try to guess whether the clang used will work.

This change omits the amdhsa-code-object-version parameter when it matches the
default that AMDGPUBaseInfo.cpp specifies, with a comment to indicate why. As
this is the only part of clang's codegen for amdgpu that depends on the target
in the back end it suffices to build the openmp runtime on most (all?) systems.

It is a non-functional change, though observable in the updated tests and when
compiling with -###. It may cause minor disruption to the amd-stg-open branch.

Revision of D98746, builds on refactor in D101077

Reviewed By: yaxunl

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

This reverts commit a683abe5.

Broke the upstream buildbots:
https://lab.llvm.org/buildbot/#/builders/37/builds/3731/steps/16/logs/stdio

In 10b781fb this test was changed to use
the -debug-only flag, which means it now requires asserts aka a
non-release compiler.

This functionality is tested in std/containers/sequences/vector/iterators.pass.cpp
(and similarly for all containers, but vector is the only one to be tested that
uses debug iterators).

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

Make it a static function RISCVISelLowering, the only place it
is used.

I think I'm going to make this return a fractional LMULs in some
cases so I'm sorting out where it should live before I start
making changes.

[RISCV] Only expose one interface for getContainerForFixedLengthVector in the RISCVTargetLowering class

We can have RISCVISelDAGToDAG.cpp call the VT only version by
finding the RISCVTargetLowering object via the Subtarget.

Make the static versions just global static functions in
RISCVISelLowering that can be called by static functions in that
file.

We were taking a reference to a value in `loadedDylibs`, which in turn
called `make<DylibFile>()`, which could then recursively call
`loadDylibs`, which would then potentially resize `loadedDylibs` and
invalidate that reference.

Fixes PR50101.

Reviewed By: #lld-macho, oontvoo

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

I was a bit confused by the comment because I thought that "Tests
that..." was describing the tests contained within the same file.

Reviewed By: #lld-macho, thakis

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

Simple fix for build breakage. Feel free to fix all places (quite a lot).

While doing speculative execution opt, it conservatively drops all insn's debug info in the merged `ThenBB`(see the loop at line 2384) including the dangling probe. The missing debug info of the dangling probe will cause the wrong inference computation.

So we should avoid dropping the debug info from pseudo probe, this change try to fix this by moving the to-be dangling probe to the merging target BB before the debug info is dropped.

Reviewed By: hoy, wenlei

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

Instead of conditionally overwriting a nullptr and then branching on its
nullness, just branch directly on the original condition. Then we can
make both pointers (non-null) references instead.