This code clearly intended to forward the error, but instead
returned the non-error result.

Use proper error reporting instead of report_fatal_error().

If possible, forward the inner error instead of creating a new
one.

Even if the reference itself is dllexport, the temporary should not be.
In fact, we're already giving it internal linkage, so dllexporting it
is not just wasteful, but will fail to link, as in the example below:

  $ cat /tmp/a.cc
  void _DllMainCRTStartup() {}
  const int __declspec(dllexport) &foo = 42;

  $ clang-cl -fuse-ld=lld /tmp/a.cc /Zl /link /dll /out:a.dll
  lld-link: error: <root>: undefined symbol: int const &foo::$RT1

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

CMAKE_CXX_STANDARD 14 is set in the llvm-project/llvm folder overriding all COMPILE_OPTIONS -std=c++17.  We need to override the CXX_STANDARD property of the target in order to set the correct C++ standard flags.

Reviewed By: gchatelet

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

New device library supporting v4 and v5 has abi_version_400.bc and abi
version_500.bc.

For v5, abi_version_500.bc is linked.

For v2-4, abi_version_400.bc is linked.

For old device library, for v2-4, none of the above is linked. For v5,
error is emitted about unsupported ABI version.

Reviewed by: Artem Belevich

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

Fixes: SWDEV-321313

Only call offsetsCanBeCombined with Modify = true in cases
where it will really do something. NFC.

This is to reflect changes introduced by https://reviews.llvm.org/D118860.

[NFC][SVE] Change useSVEForFixedLengthVectorVT to allow unconditional SVE usage for NEON sized vectors.

Previously useSVEForFixedLengthVectorVT only allowed SVE usage when
the target SVE register length was known to be at least 256bit.
This was true even for NEON sized vectors, which was an artificial
restriction imposed during early SVE bring up.  This now changes so
that callers can opt to use SVE for NEON sized vectors regardless
of the SVE register length.

The patch is NFC because for all places where OverrideNEON is used
we now explicitly also check that SVE code generation for larger
than NEON vectors is enabled.  The intent is that over time these
extra checks will either be removed or the lowering disabled if the
SVE usage proves not beneficial.

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

Also add a comment explaining the difference between class
and subclass. NFCI.

We already had some patterns for UADDV(UADDLP(x)) -> UADDLV(x), this
simply expands them to the signed instructions by re-using the tablegen
patterns.

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

While nowadays SimplifyCFG knows how to hoist code from then-else blocks,
sink code from unconditional predecessors, and even promote the latter
by tail-merging `ret`/`resume` function terminators, that isn't everything.

While i (& others) have been trying to deal with merging/sinking `unreachable`,
apparently perhaps the more impactful remaining problem is merging the `throw`
calls.

If we start at the `landingpad`, all the predecessors are unwind edges of `invoke`s,
and in some cases some of the `invoke`s are mergeable.
```
/// This is a weird mix of hoisting and sinking. Visually, it goes from:
///          [...]        [...]
///            |            |
///        [invoke0]    [invoke1]
///           / \          / \
///     [cont0] [landingpad] [cont1]
/// to:
///      [...] [...]
///          \ /
///       [invoke]
///          / \
///     [cont] [landingpad]
```

This simplifies the IR/CFG, at the cost of debug info and extra PHI nodes.

Note that we don't require for *all* the `invokes` of the `landingpad`
to be mergeable, they can form more than a single set, we gracefully handle that.

For now, i completely disallowed normal destination, PHI nodes and indirect invokes
but that can be supported.

Out of all the CTMark projects, only 7zip is C++, so there isn't much impact:
https://llvm-compile-time-tracker.com/compare.php?from=ba8eb31bd9542828f6424e15a3014f80f14522c8&to=722fc871c84f14157d45c2159bc9c8c7e2825785&stat=size-total
... but there it currently causes size-total decrease.

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

This patch adds initial support for signed conditions. To do so,
ConstraintElimination maintains two separate systems, one with facts
from signed and one for unsigned conditions.

To start with this means information from signed and unsigned conditions
is kept completely separate. When it is safe to do so, information from
signed conditions may be also transferred to the unsigned system and
vice versa. That's left for follow-ups.

In the initial version, de-composition of signed values just handles
constants and otherwise just uses the value, without trying to
decompose the operation. Again this can be extended in follow-up
changes.

The main benefit of this limited signed support is proving >=s 0
pre-conditions added in D118799. But even this initial version also
fixes PR53273.

Depends on D118799.

Reviewed By: reames

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

[NFC][SimplifyCFG] 'merge compatible invokes': test with PHI nodes in unreachable normal destinations

Based on the LangRef change in D117890, this uses the elementtype
attribute rather than the pointer element type to determine the
statepoint callee function type, making statepoints compatible
with opaque pointers.

This enforces the requirement specified in D117890.

Common up all the calls to CI.setMI. NFCI.

This updates tests for the LangRef change in D117890.

At this point CI represents the combined access (original CI combined
with Paired) so it doesn't make any sense to add in Paired.width again.
NFCI.

These operations are scalarized but the result type v1i1 isn't which
needs special handling (the same as is done for the non-strict
versions of these operations).

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

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

This reverts commit b4b97ec8.

As discussed in post-commit feedback at:
https://reviews.llvm.org/D118376
...there's a stage 2 failure on a Mac running a clang-refactor tool test.

after the recent refactor, the function is unused.

OpenMP Spec 5.0 [2.12.5, Restrictions]: If a device clause in which the
ancestor device-modifier appears is present on the target construct,
then a requires directive with the reverse_offload clause must be
specified.

Reviewed By: ABataev

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

Remove the vector base class as suggested by @ldionne

Reviewed By: ldionne, Quuxplusone, #libc

Spies: libcxx-commits, ldionne

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

With this patch pre-conditions can be added to a list of constraints.
Constraints with pre-conditions can only be used if all pre-conditions
are satisfied when the constraint is used.

The pre-conditions at the moment are specified as a list of
(Predicate, Value *,Value *) tuples. This allow easily checking them
like any other condition, using the existing infrastructure.

This then is used to limit GEP decomposition to cases where we can
prove that offsets are signed positive.

This fixes a couple of incorrect transforms where GEP offsets where
assumed to be signed positive, but they were not.

Note that this effectively disables GEP decomposition, as there's no
support for reasoning about signed predicates. D118806 adds initial
signed support.

Fixes PR49624.

Reviewed By: reames

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

The second space in `void foo() &` is always produced by clang-format,
and isn't evidence of any particular style.

Before this patch, it was considered evidence of PAS_Right, because
there is a space before a pointerlike ampersand.

This caused the following code to have "unstable" pointer alignment:
  void a() &;
  void b() &;
  int *x;
PAS_Left, Derive=false would produce 'int* x' with other lines unchanged.
But subsequent formatting with Derive=true would produce 'int *x' again.

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

Some types (e.g. `_Bool`) have different scalar and memory representations. CodeGen for `va_arg` didn't take this into account, leading to an assertion failures with different types.

This patch makes sure we use memory representation for `va_arg`.

Reviewed By: ahatanak

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

Add a dummy clang-pseudo tool (right now it accepts and parses the
grammar file).

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

This header is very large (3M Lines once expended) and was included in location
where dwarf-specific information were not needed.

More specifically, this commit suppresses the dependencies on
llvm/BinaryFormat/Dwarf.h in two headers: llvm/IR/IRBuilder.h and
llvm/IR/DebugInfoMetadata.h. As these headers (esp. the former) are widely used,
this has a decent impact on number of preprocessed lines generated during
compilation of LLVM, as showcased below.

This is achieved by moving some definitions back to the .cpp file, no
performance impact implied[0].

As a consequence of that patch, downstream user may need to manually some extra
files:

llvm/IR/IRBuilder.h no longer includes llvm/BinaryFormat/Dwarf.h
llvm/IR/DebugInfoMetadata.h no longer includes llvm/BinaryFormat/Dwarf.h

In some situations, codes maybe relying on the fact that
llvm/BinaryFormat/Dwarf.h was including llvm/ADT/Triple.h, this hidden
dependency now needs to be explicit.

$ clang++ -E  -Iinclude -I../llvm/include ../llvm/lib/Transforms/Scalar/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
after:   10978519
before:  11245451

Related Discourse thread: https://llvm.discourse.group/t/include-what-you-use-include-cleanup
[0] https://llvm-compile-time-tracker.com/compare.php?from=fa7145dfbf94cb93b1c3e610582c495cb806569b&to=995d3e326ee1d9489145e20762c65465a9caeab4&stat=instructions

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

This patch adds partial lowering of the "GET_COMMAND_ARGUMENT"
intrinsic to the backend runtime hook implemented in patches D109227,
D109813, D109814.

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

This is in preparation for adding the OpenCL 3.0 builtins with named
address space arguments.

Generate movprfx for floating point convert zeroing pseudo operations

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

It's fishy that this is needed, but this is what the test did
previously. Should hopefully address buildbot failures.

- add logically missing test cases.
- add appropriate comments.
- add appropriate TODO's.

See initial motivation in https://reviews.llvm.org/D117302

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

This patch handles the quiet argument in the STOP statement. It adds
ability to lower LOGICAL constant.

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

Reviewed By: kiranchandramohan, PeteSteinfeld

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



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

To be consistent with existing name pattern.