This change removes an unnecessary branch from a hot path. It's also
questionable API to override any previous error unconditonally.

The script is based on an example provided by Tim
Northover (https://github.com/TNorthover).

Followup to #73729

If looking for a miscompile revert candidate, look here!

The transform being enabled prefers comparing to a loop invariant
exit value for a secondary IV over using an otherwise dead primary
IV.  This increases register pressure (by requiring the exit value
to be live through the loop), but reduces the number of instructions
within the loop by one.

On RISC-V which has a large number of scalar registers, this is
generally a profitable transform.  We loose the ability to use a beqz
on what is typically a count down IV, and pay the cost of computing
the exit value on the secondary IV in the loop preheader, but save
an add or sub in the loop body.  For anything except an extremely
short running loop, or one with extreme register pressure, this is
profitable.  On spec2017, we see a 0.42% geomean improvement in
dynamic icount, with no individual workload regressing by more than
0.25%.

Code size wise, we trade a (possibly compressible) beqz and a (possibly
compressible) addi for a uncompressible beq.  We also add instructions
in the preheader.  Net result is a slight regression overall, but
neutral or better inside the loop.

Previous versions of this transform had numerous cornercase correctness
bugs.  All of them ones I can spot by inspection have been fixed, and I
have run this through all of spec2017, but there may be further issues
lurking.  Adding uses to an IV is a fraught thing to do given poison
semantics, so this transform is somewhat inherently risky.

This patch is a reworked version of D134893 by @eop.  That patch has
been abandoned since May, so I picked it up, reworked it a bit, and
am landing it.

This document describes the aspects of Fortran descriptor management
in the offload data environment and how this semantics can be
represented using MLIR OpenACC dialect.

In the document I tried to clarify some parts of the OpenACC
specification that seemed unclear to me, e.g. where the spec allowed different
interpretations (in my opinion) or did not specify the actual runtime
behavior. I tried to demonstrate how this ambiguity can affect user
programs with examples.

The document proposes using `attachRecipe` on the data operations
to represent the non-trivial pointer attachment semantics for variables
represented by descriptors. The recipe provides the actual
implementation of the pointer attachment, e.g. we can call an F18 offload runtime
function that will perform all necessary checks and actions.

It is unclear at this point if we want to expose the implementation
details in FIR, otherwise, the recip...

[mlir] Adopt `ConvertToLLVMPatternInterface` GpuToLLVMConversionPass to align with `convert-to-llvm` (#73761)

This is a follow-up to the introduction of `convert-to-llvm`: it is
supposed to be a unifying pass through the
`ConvertToLLVMPatternInterface`, but some specific conversion (like the
GPU target) aren't vanilla LLVM target. Instead they need extra
customizations that are specific to LLVM-on-GPUs and our custom runtime
wrappers.
This change make the GpuToLLVMConversionPass just as pluggable as the
`convert-to-llvm` by using the same mechanism.

Add missing constant propogation folder for IAddCarry and
[S|U]MulExtended. Due to currently missing constant value for
spirv.struct the folding is done using canonicalization patterns.

Implement additional folding when rhs is 0 for all ops and when rhs is 1
for UMulExt.

This helps for readability of lowered code into SPIR-V.

Part of work for #70704

A previous patch to llvm allowed the DWARFUnitIndex class to handle
.debug_info.dwo and .debug_types.dwo sections to go over 4GB by checking
for this case and fixing up the DWARFUnitIndex. LLDB's DWARF parser
tries to use the llvm's DWARF parser when it can, and LLDB's DWARF
parser uses the llvm::DWARFUnitIndex which should allow us to load large
.dwp files, but there were a few things missing on the LLDB front:
- support for parsing DWARFUnit objects when the offset exceeds 4GB due
to a 32 bit truncation issue
- not populating the required DWARF sections when we call
DWARFContext::GetAsLLVM() which didn't allow the fixups to happen as the
data was missing.

This patch fixes these issues and now allows LLDB to parse large .dwp
files without issues. The issue was discovered when running the "target
modules dump separate-debug-info" command on one of these binaries that
used a large .dwp file.

This is unfortunately hard to test without creating a huge .dwp file, so
there are currently no tests for this that I can think of adding that
wouldn't cause disk space constraints or making testing times longer by
producing a huge .dwp file.

This was a copy/paste mistake from sig0/sig1 which have high and low halves.
sum0 and sum1 have sum0r and sum1r instead.

Co-authored-by: Edgar <git@edgarluque.com>

Follow up on 59edb432 (clang/APINotes: squelch a -Wparantheses warning
(NFC)) to fix parenthesization, as requested by David Blaikie.

Add missing constant propogation folder for [S|U]Mod, [S|U]Div, SRem

Implement additional folding when rhs is 1 for all ops.

This helps for readability of lowered code into SPIR-V.

Part of work for #70704

The comment about the stripping of suffixes when creating the indexed
MemProf profile was partially incorrect, as we do not strip ".__uniq."
suffixes by default (by design). Update the comment accordingly.

While this does not really encapsulate the mapping code, it at least
moves most of the declarations out of the way.

This fixes the test to handle the changes in the AST printer.
../clang/test/SemaHLSL/Types/BuiltinVector/ScalarSwizzles.hlsl

This is the last patch for fabs lowering. v32f16 works for AVX as well
with the patch (with type legalization).

HLSL supports vector swizzles on scalars by implicitly converting the
scalar to a single-element vector. This syntax is a convienent way to
initialize vectors based on filling a scalar value.

There are two parts of this change. The first part in the Lexer splits
numeric constant tokens when a `.x` or `.r` suffix is encountered. This
splitting is a bit hacky but allows the numeric constant to be parsed
separately from the vector element expression. There is an ambiguity
here with the `r` suffix used by fixed point types, however fixed point
types aren't supported in HLSL so this should not cause any exposable
problems (a separate issue has been filed to track validating language
options for HLSL: #67689).

The second part of this change is in Sema::LookupMemberExpr. For HLSL,
if the base type is a scalar, we implicit cast the scalar to a
one-element vector then call back to perform the vector lookup.

Fixes #56658 and #67511

This update makes the user visible messages relating to features that
are not yet implemented be more consistent. I also cleaned up some of
the code.

For NYI messages that refer to intrinsics, I made sure the the message
begins with "not yet implemented: intrinsic:" to make them easier to
recognize.

I created some utility functions for NYI reporting that I put into
.../include/Optimizer/Support/Utils.h. These mainly convert MLIR types
to their Fortran equivalents.

I converted the NYI code to use the newly created utility functions.

StandardConversionSequence is significantly larger than a word.

"private.h" will go.

This reverts commit caba0314.

Serious performance regressions were reported by @vzakhari
https://github.com/llvm/llvm-project/issues/58303#issuecomment-1830754173

Fixing this doesn't look quick so I will revert for now.

It was previously classified as a type attribute when it is actually a
variable attribute.

This paper was voted in as a DR, so it's retroactively enabled back to
C++20; the C++ version that introduced std::format.

Implements:
- P2909R4 Fix formatting of code units as integers (Dude, where’s my
``char``?)

Also revert the ifdef OMPT_SUPPORT order to have the short fallback
first and not after 400 lines.

Work towards removing method Type::getPointerTo.
Opaque ptr cleanup effort.

CodeExtractor shifts dbg.value intrinsics out of the region being
extracted and updates them to be appropriate in the extracted function.
With new non-intrinsic variable locations, we need to manually do this
too, with DPValues.

Most of this patch shifts and refactors some utilities in
fixupDebugInfoPostExtraction so that we can add a single extra helper
lambda that iterates over DPValues and applies update-utilities. We also
have to assign the IsNewDbgInfoFormat flag in a bunch of places -- this
normally gets set the moment you insert a block into a function (or
function into a module), however a few blocks are constructed here
before being inserted, thus we have to do some manual setup.

Tested via LoopExtractor_alloca.ll, which invokes debugify.

This enables -regalloc=greedy to memfold spillable inline asm
MachineOperands.

Because no instruction selection framework marks MachineOperands as
spillable, no language frontend can observe functional changes from this
patch. That will change once instruction selection frameworks are
updated.

Link: https://github.com/llvm/llvm-project/issues/20571

This got "lost" in the HLFIR transformation. This patch applies the old
attribute to the AssociateOp that needs it, and forwards it to the
AllocaOp that is generated when lowering to FIR.

Currently PresentModifierLocs defined with size DefaultmapKindNum; where
DefaultmapKindNum = OMPC_DEFAULTMAP_pointer + 1

Before 5.0 variable-category can not be omitted. For the test like
\#pragma omp target map(tofrom: errors) defaultmap(present)

error would be mitted.

After 5.0 that is allowd.

When try to:
PresentModifierLocs[DMC->getDefaultmapKind()] =
              DMC->getDefaultmapModifierLoc();
It is accessed beyond array end.

To fix this using OMPC_DEFAULTMAP_unknow instead OMPC_DEFAULTMAP_poiner.

For historic reasons we had it setup that there was
`  plugin-nextgen/common/PluginInterface/<sources + headers>`
which is not what we do anywhere else.
Now it looks like the rest:
```
  plugin-nextgen/common/include/<headers>
  plugin-nextgen/common/src/<sources>
```
As part of this, `dlwrap.h` was moved into common/include (as
`DLWrap.h`)
since it is exclusively used by the plugins.

This should not be needed now that the project uses PRs, plus the
OpenSSF Scorecard report flagged this as insecure.

This flag was added in #67982, but was not yet accessible via the C API.
This commit adds a getter/setter for this flag, and a test for it.

Picolibc is a C Standard Library that is commonly used in embedded
environments. This patch adds initial support for this configuration
along with pre-commit CI. As of this patch, the test suite only builds
the tests and nothing is run. A follow-up patch will make the test suite
actually run the tests.

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