`tileToForallOpImpl` takes only one target instead of a list of all targets.

This is in preparation of D149847.

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

[Flang][OpenMP][Sema] More gracefully handle undefined symbol in a no implicit module for declare target

Prior to this change, if you define a module as such with a declare target in it:

module test_0
    implicit none
!$omp declare target(no_implicit_materialization_1)
end module test_0

The compiler will crash rather than give some form of reasonable
diagnostic. This patch attempts to fix that.

Reviewers: kiranchandramohan

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

Remove redundant CHECK lines. This test does not use FileCheck.

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

The purpose of this patch is to Implement registration of callback functions in the generic plugin by looking up corresponding callbacks in libomptarget. The overall design document is https://rice.app.box.com/s/pf3gix2hs4d4o1aatwir1set05xmjljc

Defined an object of type OmptDeviceCallbacksTy in the amdgpu plugin for holding the tool-provided callback functions. Implemented a global constructor in the plugin that creates a connector object to connect with libomptarget. The callbacks that are already registered with libomptarget are looked up and registered with the plugin.

Combined with an internal patch from Dhruva Chakrabarti, which fixes the OMPT initialization ordering.
Achieved through removal of the constructor attribute from ompt_init.

Patch from John Mellor-Crummey <johnmc@rice.edu>
With contributions from:
Dhruva Chakrabarti <Dhruva.Chakrabarti@amd.com>
Michael Halkenhaeuser <MichaelGerald.Halkenhauser@amd.com>

Reviewed By: dhruvachak, tianshilei1992

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

The tests are pulled out from https://reviews.llvm.org/D149842 as a
preparatory change.

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

This leads to a bunch of trivial test churn, plus some extra test changes
that are purely due to update_test_checks.

Pulled out of https://reviews.llvm.org/D149842 as a preparatory change.

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

This reverts commit caa95c24.

The next step will be to begin adding generic legalization/lowering support

This reverts commit a9919db6.

This patch resolves an issue where a value
is incorrectly displayed if it is represented
by DW_OP_div.

This issue is caused by lldb evaluating
operands of DW_OP_div as unsigned
and performed unintended unsigned
division.

This issue is resolved by creating two
temporary signed scalar and performing
signed division.

(Addresses GH#61727)

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

Data race scenario:
```
Thread 1                                | Thread 2
ReportTagMismatch()                     |
Call VisitAllLiveThreads() to scan all  |
threads' ring buffers to find           |
if it's a heap-use-after-free.          |
Lock live_list_mutex_                   |
                                        | Thread 2 exit
                                        | ReleaseThread() calls Thread::Destroy() for Thread 2,
                                        | which frees heap alloctions ring buffer
                                        | RemoveThreadFromLiveList() tries to take live_list_mutex_ again
Iterate the heap alloctions ring buffer |
of Thread 2, which is already freed     |
```

Reviewed By: vitalybuka

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

Directly use the canonical index type, rather than canonicalizing
it afterwards.

This patch adds the necessary constraint classes that are be used
by IRDL to define Operation, Type, and Attribute verifiers.

A constraint is a class inheriting the `irdl::Constraint` class,
which may call other constraints that are indexed by `unsigned`.
A constraint represent an invariant over an Attribute.

The `ConstraintVerifier` class group these constraints together,
and make sure that a constraint can only identify a single
attribute. So, once a constraint is used to check the
satisfiability of an `Attribute`, the `Attribute` will be
memorized for this constraint. This ensure that in IRDL, a
single `!irdl.attribute` value only correspond to a single
`Attribute`.

Depends on D144693

Reviewed By: Mogball

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

Separate the part which is specific for assume intrinsic from the part which only requires an icmp,
so that the latter could be reused for other purposes (e.g. in dominating conditions).

Differential Revision: https://reviews.llvm.org/D149940
Reviewed By: nikic

For builtin functions, we create a Function instance without a body or
code. When emitting diagnostics from them, we need a proper SourceInfo
to point to, but the only thing we can use is the call site of the
builtin function.

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

There is a lot of copy-paste-ish checks while this can be done once.

Differential Revision: https://reviews.llvm.org/D149939
Reviewed By: nikic

Reviewed By: csigg

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

Instead of equality comparison of value to preferred zero we can check just
the sign of value and if sign is set we should put this value as second operand for minimum
and first operand for maximum.
In this case FMIN/FMAX will choose the right result for 0.f and -0.f comparison.

This allows us:
1. avoid loading of big 64-bit constant for fminimum.
2. for double on non-64-nib platform we need to check only high part of value.
3. test against zero to check sign takes less size of instruction

Additionally, if we know that any of value is guaranteed to be non-zero
we should not care about 0.f and -0.f comparison.

Reviewed By: e-kud
Differential Revision: https://reviews.llvm.org/D149812

Mitigate https://github.com/llvm/llvm-project/issues/62348

The root cause for the above issue is that we used a textbook dataflow
analysis for the cross suspend point information. The analysis is
powerful but not scaling.

It is not easy to improve the current algorithm and the patch tries to
prune some branches to mitigate the problems.

Before the patch:

```
n: 20000

real	0m11.081s
user	0m10.597s
sys	0m0.320s

n: 40000

real	0m32.927s
user	0m31.403s
sys	0m1.043s

n: 60000

real	1m2.145s
user	0m58.903s
sys	0m2.268s

n: 80000

real	1m47.143s
user	1m41.630s
sys	0m3.857s

n: 100000

real	2m34.758s
user	2m26.587s
sys	0m5.922s
```

After the patch:

```
n: 20000

real	0m10.418s
user	0m9.945s
sys	0m0.311s

n: 40000

real	0m27.884s
user	0m26.430s
sys	0m1.036s

n: 60000

real	0m52.420s
user	0m49.321s
sys	0m2.267s

n: 80000

real	1m25.389s
user	1m20.247s
sys	0m3.856s

n: 100000

real	2m4.275s
user	1m56.405s
sys	0m5.975s
```

This patch intended to be a NFC patch.

There are a few inaccuracies with how FuncSpec handles global
variables.

When specialisation on non-const global variables is disabled (the
default) the pass could nevertheless perform some specializations,
e.g. on a constant GEP expression, or on a SSA variable, for which the
Solver has determined it has the value of a global variable.

When specialisation on non-const global variables is enabled, the pass
would skip non-scalars, e.g. a global array, but this should be
completely inconsequential, a pointer is a pointer.

Reviewed By: SjoerdMeijer

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

Change-Id: Ic73051b2f8602587306760bf2ec552e5860f8d39

v2:
- simplify the escape to TableGen patterns

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

After applying FMIN/FMAX, if any of operands is NaN, the second operand will be the result.
So all we need is to check whether first operand is NaN and return it or result of FMIN/FMAX.

So we avoid usage of constant NaN in the lowering.

Additionally we can avoid handling NaN after FMIN/FMAX if we are sure that first operand is not NaN.

Reviewed By: e-kud
Differential Revision: https://reviews.llvm.org/D149729

Emit FNMADD instead of FNEG(FMADD) for optimization levels
above Oz when fast-math flags (nsz+contract) permit it.

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

We are simplifying the loop and all its children. Each time, we
invalidate the top-most loop. The top-most loop is going to be
the same every time. The cost of SCEV invalidation is largely
independent from how data about the loop is actually cached, so
we should avoid redundant invalidations.

VPWidenRecipes should not be generated for scalar VFs. Replace check
with an assert. Suggested in preparation for D149081.

This commit introduces support for locations as part of the loop
annotation attribute. These locations indicate the start and the end of
the loop.

Reviewed By: gysit

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

The __objc_imageinfo section may be deleted (leaving dangling references to any
symbols that it contains), and shouldn't have any dependencies anyway. This
patch verifies that the section has no dependencies and then skips the section.

rdar://108469243

I plan to implement lowering from parse tree to HLFIR first for forall
and where to ease testing of the rewrite pass while writing it.

To avoid cryptic errors in ConvertToFir pass about unhandled operations,
this patch already defines the pass that will further lower these
operations and make it throw clear TODO messages.

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

This is the last piece required to lower Forall (except pointer
assignments, where an operation may be needed to deal with bounds
remapping).

Lowering requires symbols to be mapped to memory SSA values produced
by a fir_FortranVariableOpInterface operation. This applies to
forall index-values, that are symbols.

fir.alloca/fir.store/hlfir.declare are not allowed inside the body of
an hlfir.forall that only accept operations with the
hlfir_OrderedAssignmentTreeOpInterface so that the forall structure is
well defined and easy to transform.
Allowing such operations in the forall body would open the doors to
generating ill-formed programs where such operation would be used for
non index-values.

Instead, add an hlfir.forall_index with both required interface to
produce a memory address for a forall index.

As a bonus, since forall index-value are by nature read-only, the
loads of hlfir.forall_index can be canonicalized, which will help
simplifying the hlfir.forall nested code (it is unclear we will be
able to tell MLIR enough about hlfir.forall and hlfir.where structure
so that it could safely do a generic mem-to-reg inside it, and getting
rid of read-effect operations will benefit the forall rewrite pass).

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

This pass is useful to legalize rankless and dynamic shapes towards static using operands' shapes & types.

Reviewed By: jpienaar

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

Implements parts of **P1614R2**: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1614r2.html

- Implemented `operator<=>` for `optional`
- Updated "optional synopsis" to match the current draft https://eel.is/c++draft/optional closer
- Implemented https://cplusplus.github.io/LWG/issue3566
- Implemented https://cplusplus.github.io/LWG/issue3746

Reviewed By: #libc, philnik, ldionne

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

Reviewed By: craig.topper

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

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

Use the templated GetPropertyAtIndexAs helper for FileSpecList.

Instead of passing a constant to DecodeGPRRegisterClass, just create
the X2 register directly.