This preserves NSW flag for AddRecs multiplied by -1 if we can prove
via constant ranges that the AddRec cannot be signed minimum.

An explanation:
Let M be signed minimum. If AddRec's range contains M, then M * (-1) will
stay M and (M + 1) * (-1) will be signed maximum, so we get a signed overflow.
In all other cases if an AddRec didn't signed overflow,
then AddRec * (-1) wouldn't too.

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

Fix review comments from https://reviews.llvm.org/D146252
Merge `WhileRemoveUnusedArgs` pattern with (unused) `WhileUnusedArg`,
use `getConditionOp`, use `SmallPtrSet` and early check, move tests

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

This commit moves the CFGLoopInfo instantiation into the C++ file to
ensure that it is only compiled once. Instantiating the template
explicitly revealed two missing functions that this commit also adds.

Reviewed By: ftynse

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

Instead of using the validity of a brace's source location as a flag
for list initialization, this now uses a PointerIntPair to model it so
we do not increase the size of the AST node to track this information.
This allows us to retain the valid source location information, which
fixes the coverage assertion.

Fixes https://github.com/llvm/llvm-project/issues/62105
Differential Revision: https://reviews.llvm.org/D148245

This fixes a failing check in tests added by 05a142cc.

We often repeat the vector operand in TESTPS(X,X)/TESTPD(X,X) for anyof comparisons - ensure we still only demand the sign bits when the TESTP is the only user of that operand

Zfa provide fli instruction to load a floating point immediate value,
and some of those are not easy to write and read by human, so
hexadecimal floating-point format should be a good alternative way to write:

Consider this case: 1^-16 = 1.52587890625e-05 (decimal) vs 0x1p-16 (hexadecimal)

The hexadecimal format is easier to write for human.

Fortunately hexadecimal floating-point constants already supported in
C99, so actually we don't need to add any extra code to support that.

This patch added test case for demonstrate we support that and also make
sure this will be supported in future.

I also gonna to talk with ISA folks to adding hexadecimal floating-point
to the ISA spec, so that user will know fli accept value in this format.

Reviewed By: asb

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

This reverts commit 75f1f158.
It caused fail on https://lab.llvm.org/buildbot#builders/37/builds/21461

Adjust lowerDotProduct cost estimate to include the cost benefits of:
 * emitting a wide load
 * emitting a wide multiply.

Reviewed By: thegameg

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

[X86] Add TESTPS/TESTPD test coverage showing failure to simplify demanded sign bit when the operands has multiple uses

These case are excluded in https://reviews.llvm.org/D113049.
Now AIX XCOFF 64 integrated-as support improves a lot and all these
cases pass now, so enable them.

Remove C APIs for interacting with PassRegistry and pass
initialization. These are legacy PM concepts, and are no longer
relevant for the new pass manager.

Calls to these initialization functions can simply be dropped.

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

Currently, FunctionAttrs treats landingpads as non-throwing, and
will infer nounwind for functions with landingpads (assuming they
can't unwind in some other way, e.g. via resum). There are two
problems with this:

* Non-cleanup landingpads with catch/filter clauses do not
  necessarily catch all exceptions. Unless there are catch ptr null
  or filter [0 x ptr] zeroinitializer clauses, we should assume
  that we may unwind past this landingpad. This seems like an
  outright bug.
* Cleanup landingpads are skipped during phase one unwinding, so
  we effectively need to support unwinding past them. Marking these
  nounwind is technically correct, but not compatible with how
  unwinding works in reality.

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

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

Extra tests for D147330.

After performing signed extension, we update the register in MI. We should also update `incr` register which is tracking the register in `MI`.

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

Reviewed By: #powerpc, shchenz

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

foldAllocaCmp() needs to fold all comparisons of an alloca at the
same time, to ensure that there is a consistent view of the alloca
address. Currently, it folds "all" comparisons by limiting to the
case where there is only one. This patch switches the algorithm to
instead actually collect and fold all comparisons.

Something we need to be careful about here is that there may be
comparisons where both sides of the icmp are based on the alloca.
Such comparisons are comparing offsets of the alloca, and as such
can be ignored here, but shouldn't be folded to false.

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

Embedded systems that do not use an ELF loader locate the
.ARM.exidx exception table via linker defined __exidx_start and
__exidx_end rather than use the PT_ARM_EXIDX program header. This
means that some linker scripts such as the picolibc C library's
linker script, do not have the .ARM.exidx sections at offset 0 in
the OutputSection. For example:

.except_unordered : {
    . = ALIGN(8);
    PROVIDE(__exidx_start = .);
    *(.ARM.exidx*)
    PROVIDE(__exidx_end = .);
} >flash AT>flash :text

This is within the specification of Arm exception tables, and is
handled correctly by ld.bfd.

This patch has 2 parts. The first updates the writing of the data
of the .ARM.exidx SyntheticSection to account for a non-zero
OutputSection offset. The second part makes the PT_ARM_EXIDX program
header generation a special case so that it covers only the
SyntheticSection and not the parent OutputSection. While not strictly
necessary for programs locating the exception tables via the symbols
it may cause ELF utilities that locate the exception tables via
the PT_ARM_EXIDX program header to fail. This does not seem to be the
case for GNU and LLVM readelf which seems to look for the
SHT_ARM_EXIDX section.

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

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

PAL Metadata 3.0 introduces an explicit structure in metadata for the
programmable registers written out by the compiler backend.
Rather than using opaque registers which can change between different
architectures and requires encoding the bitfield information in the backend,
which may change between versions.

This is the initial minimal implementation that enables the use of PAL Metadata
3.0.

The change itself should be NFC for non-PAL, although the way RSRC2 register is
handled has been changed slightly.

The test is fairly minimal, but checks that the metadata format looks as
expected and verifies a couple of special cases such as tgid_[xyz]_en handling
and PsInputAddr/Ena which also change to explicit fields.

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

I believe !dereferencable violation is immediate undefined behavior,
but this was not explicitly spelled out in LangRef. We already
assume that !dereferenceable is implicitly !noundef and cannot
return poison in isGuaranteedNotToBeUndefOrPoison().

The reason why we made dereferenceable implicitly noundef is that
the purpose of this metadata is to allow speculation, and that
would not be legal on a potential poison pointer.

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

The peephole optimizer tries to replace
```
%n:sgpr_32 = S_MOV_B32 x
$scc = COPY %n
```
with a `S_MOV_B32` directly into `$scc`.

This crashes because `S_MOV_B32` cannot take `$scc` as input.

We currently generate code like this from GlobalISel when lowering a
G_BRCOND with a constant condition. We should probably look into
removing this kind of branch altogether, but until then we should at
least not crash.

This patch fixes the issue by making sure we don't apply the peephole
optimization when trying to move into a physical register that
doesn't belong to the correct register class.

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

The insertSpills() code will currently skip lifetime intrinsic users
when replacing the alloca with a frame reference. Rather than
leaving behind the dead lifetime intrinsics working on the old
alloca, directly remove them. This makes sure the alloca can be
dropped as well.

I noticed this as a regression when converting tests to opaque
pointers. Without opaque pointers, this code didn't really do
anything, because there would usually be a bitcast in between.
The lifetimes would get rewritten to the frame pointer. With
opaque pointers, this code now triggers and leaves behind users
of the old allocas.

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

 No functional changes intended.

The revision separates out the LLVM dialect definition in a separate
tablegen file and ensures the LLVMOpBase.td can include the attributes
defined by LLVMAttrDefs.td. The change allows us to use LLVM dialect
attributes in the definition of the intrinsic and memory operation
base classes, e.g. to represent alias analysis metadata using
attributes.

Reviewed By: Dinistro

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

This reverts commit 70de684d.

This causes a regression as described in #61785

/data/llvm-project/llvm/tools/llvm-exegesis/lib/BenchmarkRunner.cpp:66:2: error: extra ';' outside of a function is incompatible with C++98 [-Werror,-W
c++98-compat-extra-semi]
};
 ^
1 error generated.

This patch refactors some code out of FunctionExecutorImpl into the base
class that should be common across all implementations of
FunctionExecutor. Particularly, this patch factors out
accumulateCounterValues, and also factors out runAndSample, moving
implementation specific code into a new runWithCounter function. This
makes adding new implementations of FunctinExecutor easier.

Reviewed By: gchatelet

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

This completes the FIXME listed in FunctionExecutor in regards to
deprecating this function. It simply makes the appropriate call into
runAndSample and grabs the first counter value. This patch completely
removes the function, moving that logic into the callers (currently only
uopsBenchmarkRunner). This makes creating new FunctionExecutors easier
as an implementation no longer needs to worry about this detail.

Reviewed By: gchatelet

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

[[https://wg21.link/p1787 | P1787]]: CWG1894 and its duplicate CWG2199 are resolved per Richard’s proposal for [[ https://listarchives.isocpp.org/cgi-bin/wg21/message?wg=core&msg=28415 | “dr407 still leaves open questions about typedef / tag hiding” ]], using generic conflicting-declaration rules even for typedef, and discarding a redundant typedef-name when looking up an elaborated-type-specifier.
Wording: See changes to [dcl.typedef], [basic.lookup.elab], and [basic.lookup]/4.

Generic conflicting-declaration rules are specified in changes to [basic.scope.scope]. [[ https://cplusplus.github.io/CWG/issues/407.html | CWG407]], [[ https://cplusplus.github.io/CWG/issues/1894.html | CWG1894 ]], and [[ https://cplusplus.github.io/CWG/issues/2199.html | CWG2199 ]] discuss how elaborated type specifiers interact with typedefs, using directives, and using declarations. Since existing test for CWG407 covers examples provided in CWG1894 and CWG2199, and does it in accordance with P1787, I reused parts of it.

Reviewed By: #clang-language-wg, cor3ntin

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

This implements the server side of the approach discussed at
https://github.com/clangd/vscode-clangd/pull/193#issuecomment-1044315732

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

In the default link configuration, PLT stubs are created automatically
for R_RISCV_CALL_PLT relocations and the relocation itself is
transformed to R_RISCV_CALL (PerGraphGOTAndPLTStubsBuilder_ELF_riscv).
Only the latter is later handled when applying fixups and the former is
simply ignored.

This patch proposes to handle R_RISCV_CALL_PLT anyway when applying
fixups to support custom configurations that do not need automatic PLT
creation. An example of this is BOLT where PLT entries from the input
binary are reused (D147544).

Reviewed By: StephenFan

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

Currenty, setting the -mbb-profile-dump dumps a CSV file with blocks
inside an individual function identified by their MBB numbers. This
patch changes the MBBs to be identified by their ID which is set at MBB
creation and not changed afterwards, making it inherently stable
throughout the backend. This alleviates concerns with the MBB IDs
changing between the profile dump and what ends up in the final object
file. The MBBs inside the SHT_LLVM_BB_ADDR_MAP sections are also
identified using their MBB ID rather than number, so if we want to match
them up we need to identify the MBBs here by number.

Reviewed By: mtrofin, rahmanl

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