Branch/assume conditions in PredicateInfo are currently handled in
a rather ad-hoc manner, with some arbitrary limitations. For example,
an `and` of two `icmp`s will be handled, but an `and` of an `icmp`
and some other condition will not. That also includes the case where
more than two conditions and and'ed together.

This patch makes the handling more general by looking through and/ors
up to a limit and considering all kinds of conditions (though operands
will only be taken for cmps of course).

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

Move the unit test from InputOutputTest.cpp to FrontendActionTest.cpp
and re-implement it in terms of the FrontendActionTest fixture. This is
just a small code clean-up and a continuation of:
  * https://reviews.llvm.org/D93544

Moving forward, we should try be implementing all unit-test cases for
Flang's frontend actions in terms of FrontendActionTest.

Reviewed By: sameeranjoshi

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

_ExtInt gets stuck in the device-type-checking for __int128 if it is
between 65 and 128 bits inclusive.  Anything larger or smaller was
permitted despite this, so this is simply enabling 65-128 bit _ExtInts.
_ExtInt is supported on all our current ABIs, but we stil use the
hasExtIntType in the target info to differentiate here so that it can be
disabled.

As proposed in https://github.com/WebAssembly/simd/pull/383.

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

Also adds a isInput interface method.

... to reduce headers dependency.

Reviewed By: rampitec, arsenm

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

Run the ObjCARCContractPass during LTO. The legacy LTO backend (under
LTO/ThinLTOCodeGenerator.cpp) already does this; this diff just adds that
behavior to the new LTO backend. Without that pass, the objc.clang.arc.use
intrinsic will get passed to the instruction selector, which doesn't know how to
handle it.

In order to test both the new and old pass managers, I've also added support for
the `--[no-]lto-legacy-pass-manager` flags.

P.S. Not sure if the ordering of the pass within the pipeline matters...

Reviewed By: fhahn

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

Reviewed By: #lld-macho, compnerd

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

This reverts commit e8aec763.

F18 Clause 19.4p9 says:

  The associate names of an ASSOCIATE construct have the scope of the
  block.

Clause 11.3.1p1 says the ASSOCIATE statement is not itself in the block:

  R1102 associate-construct is:  associate-stmt block end-associate-stmt

Associate statement associations are currently fully processed from left
to right, incorrectly interposing associating entities earlier in the
list on same-named entities in the host scope.

    1  program p
    2    logical :: a = .false.
    3    real :: b = 9.73
    4    associate (b => a, a => b)
    5      print*, a, b
    6    end associate
    7    print*, a, b
    8  end

Associating names 'a' and 'b' at line 4 in this code are now both
aliased to logical host entity 'a' at line 2.  This happens because the
reference to 'b' in the second association incorrectly resolves 'b' to
the entity in line 4 (already associated to 'a' at line 2), rather than
the 'b' at line 3.  With bridge code to process these associations,
f18 output is:

 F F
 F 9.73

It should be:

 9.73 F
 F 9.73

To fix this, names in right-hand side selector variables/expressions
must all be resolved before any left-hand side entities are resolved.
This is done by maintaining a stack of lists of associations, rather
than a stack of associations.  Each ASSOCIATE statement's list of
assocations is then visited once for right-hand side processing, and
once for left-hand side processing.

Note that other construct associations do not have this problem.
SELECT RANK and SELECT TYPE each have a single assocation, not a list.
Constraint C1113 prohibits the right-hand side of a CHANGE TEAM
association from referencing any left-hand side entity.

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

When using 2 InlinePass instances in the same CGSCC - one for other
mandatory inlinings, the other for the heuristic-driven ones - the order
in which the ImportedFunctionStats would be output-ed would depend on
the destruction order of the inline passes, which is not deterministic.

This patch moves the ImportedFunctionStats responsibility to the
InlineAdvisor to address this problem.

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

It caused "Vector shift amounts must be in the same as their first arg"
asserts in Chromium builds. See the code review for repro instructions.

> Add DemandedElts support inside the TRUNCATE analysis.
>
> Differential Revision: https://reviews.llvm.org/D56387

This reverts commit cad4275d.

This reverts commit 275f30df.

As noted on the code review (https://reviews.llvm.org/D92892), this
change causes us to reject valid code in a few cases. Reverting so we
have more time to figure out what the right fix{es are, is} here.

Reviewed By: jdoerfert

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

getAPIntValue returns a const APInt& so keep it as a reference.

We already handle "vperm2x128 (ins ?, X, C1), (ins ?, X, C1), 0x31" for shuffling of the upper subvectors, but we weren't dealing with the case when we were splatting the upper subvector from a single source.

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

Exploits the instruction xxsplti32dx.

It can be used to materialize any 64 bit scalar/vector splat by using two instances, one for the upper 32 bits and the other for the lower 32 bits. It should not materialize the cases which can be materialized by using the instruction xxspltidp.

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

This patch refactors the current implementation of
`ProcessLaunchCommandOptions` to be generated by TableGen.

The patch also renames the class to `CommandOptionsProcessLaunch` to
align better with the rest of the codebase style and moves it to
separate files.

Differential Review: https://reviews.llvm.org/D95059



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

The patch adapts the rocm runtime wrapper due to subtle differences between the cuda and the rocm/hip runtime api.

Reviewed By: csigg

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

There can be muliple patterns that map to the same compressed
instruction. Reversing those leads to multiple ways to uncompress
an instruction, but its not easily controllable which one will
be chosen by the tablegen backend.

This patch adds a flag to mark patterns that should only be used
for compressing. This allows us to leave one canonical pattern
for uncompressing.

The obvious benefit of this is getting c.mv to uncompress to
the addi patern that is aliased to the mv pseudoinstruction. For
the add/and/or/xor/li patterns it just removes some unreachable
code from the generated code.

Reviewed By: frasercrmck

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

This patch adds support for producer-consumer fusion scenarios with
multiple producer stores to the AffineLoopFusion pass. The patch
introduces some changes to the producer-consumer algorithm, including:

* For a given consumer loop, producer-consumer fusion iterates over its
producer candidates until a fixed point is reached.

* Producer candidates are gathered beforehand for each iteration of the
consumer loop and visited in reverse program order (not strictly guaranteed)
to maximize the number of loops fused per iteration.

In general, these changes were needed to simplify the multi-store producer
support and remove some of the workarounds that were introduced in the past
to support more fusion cases under the single-store producer limitation.

This patch also preserves the existing functionality of AffineLoopFusion with
one minor change in behavior. Producer-consumer fusion didn't fuse scenarios
with escaping memrefs and multiple outgoing edges (from a single store).
Multi-store producer scenarios will usually (always?) have multiple outgoing
edges so we couldn't fuse any with escaping memrefs, which would greatly limit
the applicability of this new feature. Therefore, the patch enables fusion for
these scenarios. Please, see modified tests for specific details.

Reviewed By: andydavis1, bondhugula

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

Replaced CUDA builtin vars with LLVM intrinsics such that we don't need
definitions of those intrinsics.

Reviewed By: JonChesterfield

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

The loop-unswitch transform should not be performed on a loop whose
condition is divergent. For this to happen correctly, divergence
analysis must be available. The existing divergence analysis has not
been ported to the new pass manager yet. As a result, loop unswitching
on the new pass manager is currently unsafe on targets that care about
divergence.

This test is temporarily disabled to unblock work on the new pass
manager. The issue is now tracked in bug 48819.

Reviewed By: foad

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

This is another step towards removing `OperationData` and
fixing FMF matching/propagation bugs when forming reductions.

We were able to remove almost all of the state from
OperationData, so these don't make sense as members
of that class - just pass the RecurKind in as a param.

More streamlining is possible, but I'm trying to avoid
logic/typo bugs while fixing this. Eventually, we should
not need the `OperationData` class.

We were able to remove almost all of the state from
OperationData, so these don't make sense as members
of that class - just pass the RecurKind in as a param.

The documentation for contributing to LLVM currently links to the section
explaining how to submit a Phabricator review using the web interface.
I believe it would be better to link to the general page for using
Phabricator instead, which explains how to sign up with Phabricator,
and also how to submit patches using either the web interface or the
command-line.

I think this is worth changing because what currently *appears* to be our
preferred way of submitting a patch (through the web interface) isn't
actually what we prefer. Indeed, patches submitted from the command-line
have more meta-data available (such as which repository the patch targets),
and also can't suffer from missing context.

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

Loop peeling assumes that the loop's latch is a conditional branch.  Add
a check to canPeel that explicitly checks for this, and testcases that
otherwise fail an assertion when trying to peel a loop whose back-edge
is a switch case or the non-unwind edge of an invoke.

Reviewed By: skatkov, fhahn

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

This reduces template bloat, but more importantly, makes it possible to
construct one from clang-query without template types.

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

[libomptarget][devicertl] Wrap source in declare target pragmas

Factored out of D93135 / D94745. C++ and cuda ignore unknown pragmas
so this is a NFC for the current implementation language. Removes noise
from patches for building deviceRTL as openmp.

Reviewed By: tianshilei1992

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

Currently all these tests are XFAILED on Linux even though the problem
only seems to be with the few checks that look at collation. To retain
test coverage this splits the locale-dependent tests into a separate
.pass.cpp that is XFAILed as before.
This commit also XFAILs the locale-dependent tests on FreeBSD since the
[=M=] and [.ch.] behaviour for cs_CZ also doesn't seem to match the
behaviour that is expected by these tests.

Reviewed By: #libc, ldionne

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

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

Add DemandedElts support inside the TRUNCATE analysis.

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

Combined with 'da986511 - Revert "DR2064:
decltype(E) is only a dependent', this change (5a391d38) caused verifier
errors when building Chromium. See https://crbug.com/1168494#c1 for a
reproducer.

Additionally it reverts changes that were dependent on this one, see
below.

> Following up on PR48517, fix handling of template arguments that refer
> to dependent declarations.
>
> Treat an id-expression that names a local variable in a templated
> function as being instantiation-dependent.
>
> This addresses a language defect whereby a reference to a dependent
> declaration can be formed without any construct being value-dependent.
> Fixing that through value-dependence turns out to be problematic, so
> instead this patch takes the approach (proposed on the core reflector)
> of allowing the use of pointers or references to (but not values of)
> dependent declarations inside value-dependent expressions, and instead
> treating template arguments as dependent if they evaluate to a constant
> involving such dependent declarations.
>
> This ends up affecting a bunch of OpenMP tests, due to OpenMP
> imprecisely handling instantiation-dependent constructs, bailing out
> early instead of processing dependent constructs to the extent possible
> when handling the template.
>
> Previously committed as 8c1f2d15, and
> reverted because a dependency commit was reverted.

This reverts commit 5a391d38.

It also restores clang/test/SemaCXX/coroutines.cpp to its state before
da986511.

Revert "[c++20] P1907R1: Support for generalized non-type template arguments of scalar type."

> Previously committed as 9e08e51a, and
> reverted because a dependency commit was reverted. This incorporates the
> following follow-on commits that were also reverted:
>
> 7e84aa1b by Simon Pilgrim
> ed13d8c6 by me
> 95c7b6ca by Sam McCall
> 430d5d84 by Dave Zarzycki

This reverts commit 4b574008.

Revert "[msabi] Mangle a template argument referring to array-to-pointer decay"

> [msabi] Mangle a template argument referring to array-to-pointer decay
> applied to an array the same as the array itself.
>
> This follows MS ABI, and corrects a regression from the implementation
> of generalized non-type template parameters, where we "forgot" how to
> mangle this case.

This reverts commit 18e093fa.

This reverts commit c056f824.

That commit causes build failures.

As discussed on D56387, if we're shifting to extract the upper/lower half of a vXi64 vector then we're actually better off performing this at the subvector level as its very likely to fold into something.

combineConcatVectorOps can perform this in reverse if necessary.