A tail call may have $noreg operands.

Fixes a crash.

Reviewed By: xgupta

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

This is more user-friendly over an opaque crash.

Reland after fixing bad rebase.

Currently, the precense of the OpenMP target declare metadata requires
that we always codegen a global declaration. This is undesirable in the
case that we could defer or omit this declaration as is common with
unused extern variables. This is important as it allows us, in the
runtime, to rely on static linking semantics to omit unused symbols so
they are not included when the user links it in.

This patch changes the check for always emitting these variables.
Because of this we also need to extend this logic to the generation of
the offloading entries. This has the result of derring the offload entry
generation to the canonical definitoin. So we are effectively assuming
whoever owns the storage for this variable will perform that operation.
This makes an exception for `link` attributes as those require their own
special handling.

Let me know if this is sound in the implementation, I do not have the
largest view of the standards here.

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

Reviewed By: tianshilei1992

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

This is required for many trees produced in practice for i8 CodeGen.

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

Change-Id: Iac01d183d9998b15138bdc7a5051e3bed338e7d9

Fix the value of the structured attribute for entry operation in the
global constructor noted in D156353.

Reviewed By: razvanlupusoru

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

The function StripPtrCastKeepAS() no longer makes any sense, as we've
migrated to using opaque pointers throughout the codebase. Hence, remove
it. No changes to tests are required.

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

Separate parsing CTF and creating LLDB types. This is a prerequisite to
parsing forward references and recursive types.

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

[mlir][bufferization] Add DeallocOp canonicalizer to remove memrefs also present in the retained list

Since memrefs in the retained list will never be deallocated, we can remove them from the list of memrefs to be deallocated. If the list of memrefs to deallocate becomes empty, we can just delete the dealloc operation.

Reviewed By: springerm

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

This adds better support for call frame pseudos that adjust SP in
PEI::replaceFrameIndicesBackward.

Running frame index elimination backwards is preferred because it can
do backwards register scavenging (on targets that require scavenging)
which does not rely on accurate kill flags.

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

Duplicate values in the retained list can just be removed, however, for duplicates in the list of memrefs to deallocate, we also need to check the conditions and if thhey don't match, we need to compute the OR in order to not miss a case leading to a memory leak.

Reviewed By: springerm

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

X86ISelLowering takes too long to compile. Split call lowering out into
its own file so that developers working on call lowering can be more
productive.

Now one can test calling convention changes with <5s rebuilds. The rest
of X86ISelLowering still takes a long time to compile. Previous
investigations shows that lots of static functions are aggressively
inlined into the two major large switch functions, LowerOperation and
PerformDAGCombine. It may be possible to make further compile time
improvements by blocking inlining into those large dispatch functions.

clang-format complains, but I didn't want to reformat because it will
make it harder for git rename detection and blame tools.

Reviewed By: RKSimon, pengfei

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

Different identified struct types may have the same name ("").
Previously, these were deduplicated based on their name, which caused
an assertion failure when nesting identified structs:

    %0 = type { %1 }
    %1 = type { i8 }
    declare void @fn(%0)

Reviewed By: gysit

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

Closes https://github.com/llvm/llvm-project/issues/56779

Reviewed By: RKSimon, dmgreen

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

Reviewed By: #libc, Mordante

Spies: Mordante, libcxx-commits

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

Reviewed By: #libc, Mordante

Spies: Mordante, libcxx-commits

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

Consider the following pattern:

```
%binop_ = binop %x, %y
%select_ = select %c, %binop_, %x
```

If there is an identity `%identity` operand for `binop`, it is possible to transform
the above code to:
```
%opearand = select %c, %y, %identity
%result = binop %x, %operand
```
This transformation is profitable when `%identity` is all zeroes or
ones.

This patch commits a test for such patterns.

Reviewed By: craig.topper

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

[clang][DeclPrinter] Fix missing semicolon in AST print for methods that are definitions without having a body

DeclPrinter used FunctionDecl::isThisDeclarationADefinition to decide if the decl requires a semicolon at the end. However, there are several methods without body (that require a semicolon) that are definitions.

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

Reviewed By: aaron.ballman

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

Reviewed By: kristof.beyls

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

This is a followup to D151165. Instead of using the module ID, use
the module hash for sorting the import list. The module hash is what
will actually be included in the hash.

This has the advantage of being independent of the module order,
which is something that Rust relies on.

A caveat here is that the test doesn't quite work for linkonce_odr
functions, because the function may be imported from two different
modules, and the first one on the llvm-lto2 command line gets picked
(rather than, say, the prevailing copy). This doesn't really matter
for Rust's purposes (because it does not use linkonce_odr linkage),
but may still be worth addressing. For now I'm using a variant of
the test using internal instead of linkonce_odr functions.

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

Small refactorings, cosmetic changes, clean up some naming. NFCI.

Use `AddAllArgs` to keep the implementation succinct. Also adds missing
'-flang-experimental-hlfir` in "frontend-forwarding.f90"

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

Some bots were broken by 45ab2b48

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

Implement XCVbi intrinsics for CV32E40P according to the specification.

This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P.

Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, Nandni Jamnadas, @paolos, @simoncook, @xmj.

bf2ad26b originally commited.
e4777dc4 reverted due to test failures caused by a merge conflict marker in llvm/test/CodeGen/RISCV/attributes that was accidentally checked in.
This commit removed the conflict marker and recommitted.

Reviewed By: craig.topper

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

Reviewed By: MaskRay

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

Revert "[llvm-profdata] Refactoring Sample Profile Reader to increase FDO build speed using MD5 as key to Sample Profile map"

This reverts commit 66ba71d9.

Addressing issues found by:
https://lab.llvm.org/buildbot/#/builders/245/builds/11732
https://lab.llvm.org/buildbot/#/builders/187/builds/12251
https://lab.llvm.org/buildbot/#/builders/186/builds/11099
https://lab.llvm.org/buildbot/#/builders/182/builds/6976

Reviewed By: zixuan-wu

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

Based on https://discourse.llvm.org/t/rfc-what-are-the-blockers-to-turning-on-gvnsink-by-default/72326.

This patch implements a transform op for the FoldArithExtIntoContractionOp
pattern. The pattern folds arith.extf into vector.contract for the
backends with native support for mixed-mode contractions.

Reviewed By: ftynse

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

In a Unicode name was stored in a way that caused
a medial hyphen to be at the end of a a chunk, it would not
be properly ignored by the loose matching algorithm.

For example if `LEFT-TO-RIGHT OVERRIDE` was stored as
`LEFT-` [...], the `-` would not be ignored.

The generators now ensures nodes are not cut accross
medial hyphen boundaries.

Fixes #64161

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

Convert function bodies after all other operations, breaking possible declaration-reference issues between top non-LLVM Ops and non-LLVM ops inside function bodies.

Example:
```
mydialect.global @myglobal : i32
llvm.func @bar(...) {
...
%address = mydialect.global_address @myglobal : llvm.ptr
...
}
```
With the previous scheme `mydialect.global_address` always got translated before `mydialect.global`, this change ensures `mydialect.global` gets translated first.

Reviewed By: mehdi_amini

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

This is a temporary fix (for clang 17) that caps the size of
any array we try to constant evaluate:

    There are 2 limits:
      * We cap to UINT_MAX the size of ant constant evaluated array,
        because the constant evaluator does not support size_t.
      * We cap to `-fconstexpr-steps` elements the size of each individual
        array and dynamic array allocations.
        This works out because the number of constexpr steps already limits
        how many array elements can be initialized, which makes this new
        limit conservatively generous.
        This ensure that the compiler does not crash when attempting to
        constant-fold valid programs.

    If the limit is reached by a given array, constant evaluation will fail,
    and the program will be ill-formed, until a bigger limit is given.
    Or, constant folding will fail and the array will be evaluated at runtime.

    Fixes #63562

Reviewed By: efriedma

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

IdentifierResolver frees resources in the destructor but doesn't
have user-written copy c'tor or assignment operator, so copying it using
default ones can cause double free.

Reviewed By: aaron.ballman

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

CFGStmtMap frees resources in the destructor but doesn't
have user-written copy c'tor or assignment operator, so copying it using
default ones can cause double free.

Reviewed By: cor3ntin

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

DelegatingDeserializationListener frees resources in the destructor but doesn't
have user-written copy c'tor or assignment operator, so copying it using
default ones can cause double free.

Reviewed By: aaron.ballman

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