Just add the trait as acc.yield is a return like op.

Reviewed By: razvanlupusoru, jeanPerier

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

[AMDGPU][InferAddressSpaces] Only rewrite address-spaces that can be trivially casted to flat for llvm.amdgcn.flat.atomic.{fadd,fmax,fmin}

The intrinsic @llvm.amdgcn.flat.atomic.{fadd,fmax,fmin} can only be
selected for flat address spaces (constant, flat and global).

This patch restricts the cases over which GCNTTIImpl::rewriteIntrinsicWithAddressSpace
rewrites the intrinsic.

Reviewed By: arsenm

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

Make it clearer minnum(+0, +0) cannot return -0. Also remove
a note about the result always being quiet which is directly
contradicted by the following paragraph.

Handle addrspacecast when looking at uses.

AllUsesOfValueWillTrapIfNull could handle addrspacecast, but currently
doesn't.

This reverts commit e2917311.

This caused some problems with lldb testing the diagnostic output:
https://lab.llvm.org/buildbot/#/builders/68/builds/52754

Breakage:
https://lab.llvm.org/buildbot/#/builders/92/builds/44222

Show line numbers to the left of diagnostic code snippets and increase
the numbers of lines shown from 1 to 16.

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

MS link accepts *.obj with ehcont bit set only. LLD should match this
behavoir too.

Reviewed By: rnk

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

This patch adds support for DWARFv5 .debug_line_str table.
It replaces code generating line table. Instead of copying original
table and patching certain places this patch implements full line table
generation.

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

Make sure the code comments in processMemSetMemCpyDependence match
with the actual transform. They indicated that the memset being
rewritten was sunk to after a memcpy, while it actually is inserted
just before the memcpy.

Also make sure we use the debug location of the original memset
when creating the new simplified memset. In the past we've been
using the debug location for the memcpy which could be a bit
confusing.

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

RegScavenger::backward is preferred because it does not rely on accurate
kill flags.

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

This reverts commit 5cafecf9.

Buildbots are not happy with the patch.

Lots of crashes and assertion failures such as

  llvm::LegalizeRuleSet &llvm::LegalizerInfo::getActionDefinitionsBuilder(
  std::initializer_list<unsigned int>): Assertion `Opcodes.size() >= 2 &&
  "Initializer list must have at least two opcodes"' failed.

Summary:

1. we use the unsigned type for NextOffset,PrevOffset ,GlobalSymbolOffset , MemberTableSize, it will caused a malform big archive when the archive file size is large than 4G.
2. also fix a NFC comment on https://reviews.llvm.org/D142479#inline-1443927

Reviewers: James Henderson
Differential Revision: https://reviews.llvm.org/D150462

This remove a bunch of #include statements in Scalar.cpp. I do not
think those should be needed any longer (assuming that they once
upon a time possibly were needed for legacy PM C bindings, but
that is not supported any longer).

Also removing some other #include statements not needed any longer
due to deprecation of legacy PM.

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

These intrinsics are used to implement the pext intrinsics that extract
two predicates (mask) from a predicate-as-counter value, e.g.

  __attribute__((arm_streaming))
   svboolx2_t svpext_lane_c8_x2(svcount_t pnn, uint64_t imm);

As described in https://github.com/ARM-software/acle/pull/217

Reviewed By: kmclaughlin

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

These intrinsics are used to implement the pext intrinsics that extract
a predicate (mask) from a predicate-as-counter value, e.g.

   __attribute__((arm_streaming))
   svbool_t svpext_lane_c8(svcount_t pnn, uint64_t imm);

As described in https://github.com/ARM-software/acle/pull/217

Reviewed By: david-arm

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

remark: unable to legalize instruction: %95:_(s16) = G_BSWAP %94:_ (in function: _ZNK4llvm13DataExtractor6getU16EPyPtj) [-Rpass-missed=gisel-legalize]

check plan: ninja check-llvm-codegen-x86

Reviewed By: arsenm

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

https://reviews.llvm.org/D150586 removed a problematic test cases that caused failures on non-ppc buildbots. This patch revises the test case and adds it back.

Reviewed By: hubert.reinterpretcast

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

Fixes #39713

fferential Revision: https://reviews.llvm.org/D150552

In D148674, the negative condition was weakened to only
checking isKnownNever(fcNegative), instead of cannotBeOrderedLessThanZero().

This avoids a regression when CannotBeOrderedLessThanZero is
replaced with computeKnownFPClass.

Copied from CannotBeNegativeZero and extended to cover fsub.

This reverts commit a423b7f1.
See https://lab.llvm.org/buildbot/#/changes/95083

The COMPILER_RT_HAS_FLOAT16 cmake check is now set per architecture,
which needs to be reflected when building the tests.

Additionally added armhf to the architecture list.

Reviewed By: dim

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

The revision adds LLVM's is constant intrinsic.

Depends on D150643

Reviewed By: Dinistro

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

This change is necessary to set correct EFlags according to the
options (-m*-float and -mabi=) passed to clang when input is assembly.

Note: `-mabi=` is not documented by `as`.
```
$ as --version
GNU assembler (GNU Binutils) 2.40.50.20230316
...
$ as --target-help
LARCH options:
```

But we can see gcc invokes `as` and passes the `-mabi=` option when compiling C or assembly.
```
$ gcc -c a.c -v 2>&1 -msoft-float | grep "as -v"
 as -v -mabi=lp64s -o a.o /tmp/ccFrxzZi.s
$ gcc -c a.s -v 2>&1 -msoft-float | grep "as -v"
 as -v -mabi=lp64s -o a.o a.s
```

Reviewed By: xen0n

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

lp64s is same as lp64d execpt that floating point arguments and return
values are always passed via GPRs or stack which means `UseGPRForFloat`
is always `true` in `CC_LoongArch` for lp64s.

One motivation of this change is to build linux which uses
`-msoft-float` and `-mabi=lp64s` [1].

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/Makefile?h=v6.4-rc1#n49

Reviewed By: xen0n, hev

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

In practice, a Warning on every occurrence is very unpopular, even on a codebase
with clear rules about direct inclusion & moderately good compliance.

This change has various practical effects (in vscode for concreteness):
  - makes the diagnostic decoration less striking (blue vs yellow)
  - makes these diagnostics visually distinct from others when reading
  - causes these diagnostics to sort last in the "problems" view
  - allows these diagnostics to be easily filtered from the "problems" view

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

This alters the lowering of shifts by a constant, so that the type is lowered
to a v1i64 instead of a i64. This helps communicate that the type will live in
a neon register, and can help clean up surrounding code. Note this is only
currently for the scalar shifts of a constant that go through the nodes in
tryCombineShiftImm.

ssra instructions are no longer being recognized in places, but that can be
cleaned up in a followup patch that combines the i64 add into a v1i64 add.

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

Reviewed By: nikic

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

[clang][AST] Print name instead of type when diagnosing uninitialized subobject in constexpr variables

This patch improves the diagnostic on uninitialized subobjects in constexpr variables by modifying the diagnostic message to display the subobject's name instead of its type.

Fixes https://github.com/llvm/llvm-project/issues/58601
Differential Revision: https://reviews.llvm.org/D146358

check plan:  ninja check-llvm-codegen-x86

Reviewed By: arsenm

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

This is for consistency with other dialects.

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