Reviewed By: lntue

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

Motivating case: EXPECT_EQ(42, missingFunction(bar));

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

and, also update the function indirectCopyToAGPR() to ensure that it is called only on GFX908 sub-target.

Reviewed By: rampitec

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

this patch adds lowering tests for
netsed where statements

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld

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



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

This patch adds some lowering tests for globals.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld

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



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

-fsplit-machine-functions is an optimization in codegen phase. when -flto is use, clang generate IR bitcode in .o files, and linker will call into these codegen optimization passes. Current clang driver doesn't pass this option to linker when both -fsplit-machine-functions and -flto are used, so the optimization is silently ignored.  My fix generates linker option -plugin-opt=-split-machine-functions for this case. It allows the linker to pass "split-machine-functions" to code generator to turn on that optimization.  It works for both gold and lld.

Reviewed By: hoy, wenlei

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

This patch adds lowering tests for IO related use cases.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld

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



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

This patch adds a lowering test for the namelist.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld

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



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Peter Steinfeld <psteinfeld@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>

EarlyCSE currently optimizes all MemoryUses upfront. However,
EarlyCSE only actually queries the clobbering memory access for
a subset of uses, namely those where a CSE candidate has already
been identified. Delaying use optimization to the clobber query
improves compile-time in practice.

This change is not NFC because EarlyCSE has a limit on the number
of clobber queries (EarlyCSEMssaOptCap), in which case it falls
back to the defining access. The defining access for uses will now
no longer coincide with the optimized access.

If there are performance regressions from this change, we should
be able to address them by raising this limit.

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

[AArch64] Fallback to DWARF when trying to emit compact unwind info with multiple CFA offset adjustments

Instead of asserting, fallback to emitting DWARF unwind info when an
attempt is made to output compact unwind info for a function with
multiple adjustments to the CFA offset.

Multiple adjustments of SP are common and with instruction precise
unwind tables these may translate into multiple `.cfi_def_cfa_offset`
directives.

Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=1302998

Reviewed By: dmgreen

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

Debian8 is too old to build LLVM project, the version
of GCC, CMake and python are lower than the requirements:
https://llvm.org/docs/GettingStarted.html#software

Debian10 is the earliest release that has software
packages that meet the above requirements.

Reviewed By: sammccall

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

The first attempt at this missed a validity check.
This version includes a test of the narrow source
type for modulo-16-bits.

Original commit message:

This is the IR counterpart to 370ebc9d
which provided a bswap narrowing fix for issue #53867.

Here we can be more general (although I'm not sure yet
what would happen for illegal types in codegen - too
rare to worry about?):
https://alive2.llvm.org/ce/z/3-CPfo

This will be more effective if we have moved the shift
after the bswap as proposed in D122010, but it is
independent of that patch.

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

This is reduced from a crash caused by D122166.

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

Reviewed By: MyDeveloperDay, HazardyKnusperkeks, owenpan

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

Relanding as the original patch provoked an infinite loop in JavaScript/TypeScript.
A reproducer test case was added and the issue fixed.

The intrinsic computes the sin, cosine values. By default they are lowered
to runtime calls to the pgmath library, for llvm lowering they are
lowered to llvm intrinsics. The generic and llvm lowering does not
lower floating point types with kind greater than 8, the llvm lowering
does not support the complex types.

This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project

Reviewed By: clementval

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



Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

Placeholder types were not checked for constraint satisfaction when modified by references or pointers.
The behavior now matches that of GCC and MSVC.

Are there other modifiers we might need to "peel"? I'm not sure my approach to this is the 'right' way to fix this, the loop feels a bit clunky.

GitHub issues [[ https://github.com/llvm/llvm-project/issues/54443 | #54443 ]], [[ https://github.com/llvm/llvm-project/issues/53911 | #53911 ]]

Reviewed By: erichkeane

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

`DeclarationName` already takes `const IdentifierInfo *`. Propagate the
`const` outward to various APIs.

Reviewed By: aaron.ballman

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

There has been a lot of confusion on this in the past (see for
example https://reviews.llvm.org/D110634 and earlier revisions),
so let's try to get some clarity here. This patch specifies that
a) specifying a non-constant assumed alignment is explicitly
allowed and b) an invalid (non-power-of-two) alignment is not UB,
but rather converts it into an assumption that the pointer is null.

This change is done for two reasons:
a) Assume operand bundles are specifically used in cases where the
alignment is not known during frontend codegen (otherwise we'd just
use an align attribute), so rejecting this case doesn't make sense.
b) At least for aligned_alloc the C standard specifies that passing
an invalid alignment results in a null pointer, not undefined
behavior.

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

The intrinsic computes the tan and hyperbolic sin, cosine values. By
default they are lowered to runtime calls to the math library. Not all
types are supported currently. The generic and llvm lowering does not
lower floating point types with kind greater than 8, the llvm lowering
does not support the complex types.

Note: tanh is not present in fir-dev hence ignoring for now. We can add
support after upstreaming is complete. sin and cos will come in separate
patches since they have llvm intrinsic lowering.

This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project

Reviewed By: PeteSteinfeld

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



Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: William Moses <gh@wsmoses.com>

In D92191, a bunch of test cases were added to check `clang-scan-deps` works in `clang-cl` mode as well.

We don't need to duplicate all test cases, though. Testing the few special cases we have in `clang-scan-deps` for `clang-cl` should be good enough:

1. Deducing output path (and therefore target name in our make output).
2. Ignoring `-Xclang` arguments in step 1.
3. Deducing resource directory by invoking the compiler executuable.

This test de-duplicates the extra clang-cl test cases.

Reviewed By: dexonsmith, saudi

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

This patch gets rid of the ridiculous relative path we use to invoke the `module-deps-to-rsp.py` script and creates proper lit substitution, cleaning up the tests.

Reviewed By: dexonsmith

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

The way the check is written is not compatible with opaque
pointers -- while we don't need to change the IR pointer type,
we do need to change the element type stored in the Address.

The one use check here is very misleading: At this point we should
actually have no uses, because the only possible use in llvm.used
was already dropped. But because the use in llvm.used is generally
bitcasted, we end up still having one dead use here.

What we actually want to check is that there are no live uses, for
which a helper has recently been added.

This code is supposed to clean up a constexpr bitcast/GEP, but
with opaque pointers this ends up dropping references to the
global.

As we're going to reassign the initializer, we actually need the
value types to match, not just the pointer types. This is only
relevant with opaque pointers.

With opaque pointers, the bitcast constexpr will not be present.

* Check for warnings instead of using -Werror, to avoid masking the
type of diagnostic emitted

* use different -verify labels instead of using conditional
compilation of diagnostic checks

Reviewed By: aaron.ballman

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

This patch some lowering tests for characters related operations.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld

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



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>

This patch adds various lowering test
for calls.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld

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



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Mats Petersson <mats.petersson@arm.com>

This patch adds some lowering tests.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld

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



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

This patch adds a lowering test for the C
interoperability.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld

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



Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

This patch extends the support for C/C++ operators for SVE
types to allow one of the arguments to be a scalar, in which
case a vector splat is performed.

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

This amends a749e329 to fix a few
missed targets in the contributor documentation.

Should fix https://lab.llvm.org/buildbot#builders/57/builds/16192 introduced by
02c28970

`HeaderSearch` currently assumes `LookupFileCache` is eventually populated in `LookupFile`. However, that's not always the case with `-fms-compatibility` and its early returns.

This patch adds a defensive check that the iterator pulled out of the cache is actually valid before using it.

(This bug was introduced in D119721. Before that, the cache was initialized to `0` - essentially the `search_dir_begin()` iterator.)

Reviewed By: dexonsmith, erichkeane

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

This change fixes a crash in RangedConstraintManager.cpp:assumeSym due to an
unhandled BO_Div case.

clang: <root>clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp:51:
  virtual clang::ento::ProgramStateRef
  clang::ento::RangedConstraintManager::assumeSym(clang::ento::ProgramStateRef,
    clang::ento::SymbolRef, bool):
  Assertion `BinaryOperator::isComparisonOp(Op)' failed.

Reviewed By: NoQ

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