Currently we keep an internal buffer of device memory that is used to
indicate ownership of a port. Since we only use this as a single bit we
can simply turn this into a bitfield. I did this manually rather than
having a separate type as we need very special handling of the masks
used to interact with the locks.

Reviewed By: JonChesterfield

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

We currently don't extract vector elements from multi-use build vectors unless TLI.aggressivelyPreferBuildVectorSources accepts them, which seems a little extreme for constant build vectors (especially as under some cases ComputeKnownBits will indirectly extract the data for us).

This is causing a few regressions in some upcoming SimplifyDemandedBits work I'm looking at, all of which just need to know that the element is zero, so I've tweaked the fold to accept zero elements as well, which will typically fold very easily.

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

This functionality has been replaced by TypeCasters (see D151840)

depends on D154468

Reviewed By: ftynse

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

    As a request in https://reviews.llvm.org/D152205

This reverts commit eca8b54a.

Another user reverted the patch this was based on leaving this one in a
broken state.

This patch sets 'polymorphic' attribute of hlfir::ExprType when
the value is created from a polymorphic entity.
Memoization of such ExprType involves creating a mutable descriptor
on the stack, which is initialized (as a null box) and passed to
AllocatableApplyMold with the mold being the entity from which
the ExprType value is being created.

This patch fixes "creating polymorphic temporary" TODO and also
several cases of "'fir.convert' op invalid type conversion" error.

Reviewed By: tblah

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

A previous patch made this cause an error on the GPU. We have not yet
dedicated time towards an optimial implementaiton there but we do not
want it to cause an error. We simply use the fallback routines.

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

The forcing of the linker for a new module was moved from file
clang-tidy/tools/ClangTidyModule.cpp to
clang-tidy/ClangTidyForceLinker.h.

Reviewed By: PiotrZSL

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

Broke amdgpu libc bot

This reverts commit a39c9517.

The operator++, operator++(int), operator--, and operator--(int) need to
change the month to a valid value. The wording is specified in terms of
  operator+(const month& x, const months& y) noexcept;
which has the correct behavior. The aforementioned operators instead
used ++/-- on the internal value direction, resulting in incorrect
behaviour.

As a drive-by improve the unit tests:
- use the typical constexpr test method
- test whether the month is valid after the operations
- format the tests

Fixes: https://llvm.org/PR63912

Reviewed By: #libc, ldionne

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

- No longer store the diagnostic fixits in the clangdLSPServer
- When propagating the fixit via the code action, we use the Diag
  information stored in the ParsedAST (in clangdServer.cpp)

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

This reverts commit b1d0bc0f.

Builds with expensive checks show that 'sp' isn't a valid register
in ADDXrr - an object file built without exprnsive checks enabled
disassembles as "add x15, xzr, x16", instead of the intended
"add x15, sp, x16".

A declare directive is used to specify the creation of a visible device
copy of a variable for the duration of the implicit data region as it
relates to the scope in which the variable is declared.

In order to support this, the following new operations were added:
1) `acc.global_ctor` and `acc.global_dtor`. These are used whenever the
declare directive applies to a global.
2) `acc.declare_enter` and `acc.declare_exit`. These operations are
modeled similarly to `acc.enter_data` and `acc.exit_data`. The reason
they are not modeled like `acc.data` is so that these operations can be
used both for globals and regions like functions.
3) `acc.declare_device_resident` and `acc.declare_link`. These
operations are modeled in a manner consistent with previously defined
data entry operation model.

The `acc.getdeviceptr` was generalized so that it can be used with
acc.declare_exit.

Reviewed By: clementval, vzakhari

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

Currently when inlining, any alias scope information previously attached to the call op is lost. This leads to a loss of information that could be used by alias analysis to determine that two memory access operations do not alias.

This patch fixes this issue by also taking any alias scopes of the call operation into account. These can then simply be appended onto any inlined operations.

This is analogous to the following code in LLVM: https://github.com/llvm/llvm-project/blob/1768c4597e70477af2d69f576f33400181a5f945/llvm/lib/Transforms/Utils/InlineFunction.cpp#L940

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

Reviewed By: springerm, ftynse

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

Reviewed By: gchatelet

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

This patch implements domain and range restriction for PresburgerRelation

Reviewed By: Groverkss

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

Instead of asserting merely that the flow condition doesn't imply that a variable is true, make the stronger assertion that the flow condition implies that the variable is false.

Reviewed By: ymandel, xazax.hun

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

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

Need to account reshuffling, required for the reused elements in the
buildvector nodes, which are copies (perfect match) of other nodes, but
include reused elements.

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

In most places where TransferImpOps is currently used we just have one
machine instruction, so it's doing the same thing as copyImplicitOps
anyway. In those cases where we have more than one machine
instruction the destination is written to in each instruction so any
implicit defs should appear on all of them (and we shouldn't see any
implicit refs as these pseudo-instruction don't have any register
inputs), meaning the current use of TransferImpOps is incorrect and
we should be using copyImplicitOps on all of the generated
instructions.

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

 Replace lengthy `0b...` binary form with a unified 32-bit hexadecimal
 representation for opcode.  This reduces complexity when dealing with
 opcode discontinuities.

Also add a missing FrameSetup flag on the existing add instruction.

This fixes https://github.com/llvm/llvm-project/issues/63701.

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

This builds upon D155433

Reviewed By: craig.topper

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

Unfortunately we can't use the standard splat_vector and vnot PatFrags because
they are preprocessed to vmv.v.x's, so we need to define helpers to catch
those. We can't use SplatPat either because we need to nest another fragment
inside of it.

Reviewed By: craig.topper

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

This transform looks for suitable vector transfers from global memory to shared memory and converts them to async device copies.

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

This is a follow up on D154800 and D154770 to make the code structure more principled and avoid too many nested #ifdef/#endif.

Reviewed By: courbet

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

/data/workspace/llvm-project/flang/lib/Lower/ConvertCall.cpp:1281:9: error: unused variable 'converter' [-Werror,-Wunused-variable]
  auto &converter = callContext.converter;
        ^
1 error generated.

This reimplements essentially the same logic.

ms-stlye asm block is not supported on targets like arm/hexagon.
Specify a working target as POC.

Introduced by https://reviews.llvm.org/D154983

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

These two headers both contained a strange mix of definitions related to
both patterns and non-pattern transforms. Put patterns and "populate"
functions into Patterns.h and standalone transforms into Transforms.h.

Depends On: D155223

Reviewed By: nicolasvasilache

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

This is the first and most basic and important step for inlining memory operations with alias scopes.

For correctness, it is required that any alias scopes of inlined operations are replaced with deep copies. This is necessary as otherwise the same function could be inlined twice in one function, and suddenly the alias scopes extended.
A simple example would be `foo(a, b); foo(a2, b2)`. `a` and `a2` may alias. If `foo` is inlined in both instances, the store and load operations from `foo` may suddenly claim that `a` and `a2` do not alias if we were to keep the original alias scopes.

This is analogous to the following class/code in LLVM: https://github.com/llvm/llvm-project/blob/4eef2e30d6f89328a16d4f1d6b37f1c79afe850c/llvm/lib/Transforms/Utils/InlineFunction.cpp#L985

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

Snapshot all analysing files before running the tool, this makes sure
that we analyse all files statelessly and avoid the FileManager caching issue
when running `-edit` on multiple files.

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

Other compilers include the logical default also with the
default-integer-8 setting. This patch does the same for
flang.

Reviewed By: awarzynski, sscalpone

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

These should be lowered with genOptionalValue as in D154897, but I
haven't found any cases where this code path is actually hit (flang
tests, gfortran test suite), so I don't think it would be testable.
Adding an assertion for if this code path ever becomes live.

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