The macro that opts out of `std::ranges::` functionality is called
`_LIBCPP_HAS_NO_INCOMPLETE_RANGES`, and is unrelated to this macro
which is specifically about _compiler_ support for the _syntax_.

The only non-mechanical diff here is in `<__config>`.

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

The spec doesn't seem to be written as if Zfh implies Zfhmin. They
seem to be separate extensions.

This patch moves the instructions from Zfhmin to be enabled with
either the Zfh or Zfhmin extensions.

Reviewed By: achieveartificialintelligence

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

Zfhmin should imply F just like Zfh.

Reviewed By: achieveartificialintelligence

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

This patch adds partial lowering of the "COMMAND_ARGUMENT_COUNT" intrinsic
to the backend runtime hook implemented in patch D109048. Also adds a
"helper" function for retrieving the default integer type from
FIRBuilder, which will be used later when finishing the lowering of
intrinsic.

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

Add test coverage for `vector<bool>::reference`

Reviewed By: Quuxplusone, ldionne, #libc

Spies: libcxx-commits

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

This patch shuffles some functions around so that some blocks of code can
be reused. In particular,
 * Move the determination of "which blocks are in scope" to its own
   function, as it's non-trivial to solve. Delete the "InScopeBlocks"
   collection too, which nothing reads from.
 * Split transfer emission (i.e., installing DBG_VALUEs into blocks) into
   its own function.
 * Name some useful types.
 * Rename "ScopeToBlocks" to "ScopeToAssignBlocks", as that's what the
   collection contains, blocks where assignments happen.

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

One can argue that it qualifies as a toolchain tool rather than "internal llvm
tool". This will make it part of builds which set the
LLVM_INSTALL_TOOLCHAIN_ONLY cmake option, such as the Windows installer.

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

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

Openmp executables need to find libomp and libomptarget at runtime.
This currently requires LD_LIBRARY_PATH or the user to specify rpath. Change
that to set the expected location of the openmp libraries in the install tree.

Whether rpath means rpath or runpath is system dependent. The attached test
shows that the Wl,--disable-new-dtags control interacts correctly with this feature.

The implicit rpath field is appended to any user specified ones which is ideal.

Reviewed By: jhuber6

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

Failed some buildbots, bad assumptions about structure of install path

This reverts commit a80d5c34.

This reverts commit f1842937.

Bitten by -Werror,-Wdeprecated-copy on a buildbot, alas!

This is discussed as an enhancement in D118539.

ValueIDNum is supposed to be a value type that boils down to a uint64_t,
that has some bitfields for convenience. If we use the default operator=,
we end up with each bit field being individually assigned, which is
un-necessarily slow.

Implement the assignment operator by just copying the uint64_t value of
the object. This is quicker, and matches how the comparison operators
work already. Doing so is 0.1% faster on the compile-time-tracker.

Openmp executables need to find libomp and libomptarget at runtime.
This currently requires LD_LIBRARY_PATH or the user to specify rpath. Change
that to set the expected location of the openmp libraries in the install tree.

Whether rpath means rpath or runpath is system dependent. The attached test
shows that the Wl,--disable-new-dtags control interacts correctly with this feature.

The implicit rpath field is appended to any user specified ones which is ideal.

Reviewed By: jhuber6

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

Add `ranges::in_in_out_result`

Reviewed By: Quuxplusone, Mordante, #libc

Spies: CaseyCarter, libcxx-commits, mgorny

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

Functionality in IO.h and IO.cpp have been upstreamed together with the frontend
when flang landed upstream. Those files are out of date compared with fir-dev.
These functionality will be upstreamed again when needed in the lowering process
with an up to date code and a proper review.

These files (and the functions it contains) are not currently used. Hence
removing it is NFC.

Reviewed By: kiranchandramohan

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

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

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

Normally there are heruistics in lexer to treat `//*` specially in
language modes that don't have line comments (to emit `/`). Unfortunately this
only applied to the first occurence of a line comment inside the file, as the
subsequent line comments were treated as if language had support for them.

This unfortunately only holds in normal lexing mode, as in raw mode all
occurences of line comments received this treatment, which created discrepancies
when comparing expanded and spelled tokens.

The proper fix would be to just make sure we treat all the line comments with a
subsequent `*` the same way, but it would imply breaking some code that's
accepted by clang today. So instead we introduce the same bug into raw lexing
mode.

Fixes https://github.com/clangd/clangd/issues/1003.

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

This reverts commit a6b54dda.

Apparently it is not safe to modify the condition even if it passes the
hasOneUse test, because StructurizeCFG might have other references to
the condition that are not manifest in the IR use-def chains.

Fixes a crash ('Invalid size request on a scalable vector') in visitAlloca()
when we call this function for a scalable alloca instruction, caused
by the implicit conversion of TySize to uint64_t.
This patch changes TySize to a TypeSize as returned by getTypeAllocSize()
and ensures the allocation size is multiplied by vscale for scalable vectors.

Reviewed By: sdesmalen, david-arm

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

This patch upstreams support for the Arm-v8 Cortex-X1C processor for AArch64 and
ARM.

For more information, see:
- https://community.arm.com/arm-community-blogs/b/announcements/posts/arm-cortex-x1c
- https://developer.arm.com/documentation/101968/0002/Functional-description/Technical-overview/Components

The following people contributed to this patch:
- Simon Tatham
- Ties Stuij

Reviewed By: dmgreen

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

Very similar to https://reviews.llvm.org/D101230
Fixes https://github.com/llvm/llvm-project/issues/53501

[X86] combineAnd() - per-element simplification - call SimplifyDemandedBits using mask demanded bits if SimplifyDemandedVectorElts fails

We already call SimplifyDemandedVectorElts using whether each vector mask element is zero/nonzero, this just extends this to also try SimplifyDemandedBits using the demanded bits mask generated from the nonzero elements.

This also requires an additional TargetLowering::SimplifyDemandedBits DemandedBits/DemandedElts wrapper.

If we only assign a variable value a single time, we can take a short-cut
when computing its location: the variable value is only valid up to the
dominance frontier of where the assignemnt happens. Past that point, there
are other predecessors from where the variable has no value, meaning the
variable has no location past that point.

This patch recognises this scenario, and avoids expensive SSA computation,
to improve compile-time performance.

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

This reverts commit 7b2dfe1c.

Matches ab3b8985.

Reviewed By: MaskRay

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

We can only assume bit[1] == zero if its the only demanded bit or the source is not undef/poison

If AMDGPUAnnotateUniformValues finds a load from a uniform pointer with
no potentially clobbering stores between the kernel entry point and the
load instruction, it adds noclobber metadata to the *address*. This is
unsafe because it can get applied to other loads in the same which do
have aliasing stores.

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

As raised by @efriedma on D117995 - the source must not be undef/poison to demand any bits in mul(x,x) other than bit[1]

https://alive2.llvm.org/ce/z/Cxkjen

This avoids various cases where StructurizeCFG would otherwise insert an
xor i1 instruction, and it since it generally runs late in the pipeline,
instcombine does not clean up the xor-of-cmp pattern.

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

This patches fixes the visibility and linkage information of symbols
referring to IR globals.

Emission of external declarations is now done in the first execution
of emitConstantPool rather than in emitLinkage (and a few other
places). This is the point where we have already gathered information
about used symbols (by running the MC Lower PrePass) and not yet
started emitting any functions so that any declarations that need to
be emitted are done so at the top of the file before any functions.

This changes the order of a few directives in the final asm file which
required an update to a few tests.

Reviewed By: sbc100

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

As pointed out in https://reviews.llvm.org/D93401, some methods in the
Flang driver are named inconsistently. The driver strives to follow
Flang's C++ style [1] and this patch updates these methods accordingly.

[1]
https://github.com/llvm/llvm-project/blob/main/flang/docs/C%2B%2Bstyle.md

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

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

Currently, -fdeclare-opencl-builtins always adds the generic address
space overloads of e.g. the vload builtin functions in OpenCL 3.0
mode, even when the generic address space feature is disabled.

Guard the generic address space overloads by the
`__opencl_c_generic_address_space` feature instead of by OpenCL
version.

Guard the private, global, and local overloads using the internal
`__opencl_c_named_address_space_builtins` feature.

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

The current cost-model overestimates the cost of vector compares &
selects for ordered floating point compares. This patch fixes that by
extending the existing logic for integer predicates.

Reviewed By: dmgreen

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