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

The previous code path created the elemental kernel by generating a
scalar intrinsic call using pre-prepared arguments using genIntrinsicRefCore,
which then generated the intrinsic call using genIntrinsicCall().

The problem with this approach was that the dynamically optional
arguments were marked as having no argLowering, which meant that they
were unconditionally passed by value without any check to see if they
were present.

It would be nice to put an if operation in the path for !argLowering,
doing something similar to genOptionalValue(). However, this can't be
done because it isn't clear what value should be used for the default.
If zero was used (like in genOptionalValue) this could effect the result
of MIN or MAX.

Instead, this patch re-uses the implementation for scalar dynamically
optional arguments (in non-elemental calls). This does the correct
thing, entirely ignoring absent optional arguments.

Depends On: D155292

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

Only minimal argument processing is needed here because they will be
lowered properly either by the elemental intrinsic call builder or the
lowering of the scalar call inside the elemental kernel.

Dynamically optional arrays are coming in the next patch.

Depends On: D155291

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

This should produce the same results as the FIR lowering

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

Bug #63699 shows a hang on arm in instcombine because we do not
propagate known bits for fshl/fshr rotates. We perform the propagation
and add regression test.

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

We were dropping the flags and thus blocking contract into potential
fadd users. GlobalISel was already preserving the flags here.

https://reviews.llvm.org/D155443

Prepare for new lowering strategies because we somehow didn't have
enough of them already.