The metadata added in D102361 introduces a module flag that we can check
to determine if the module was compiled with `-fopenmp` enables. We can
now check for the precense of this instead of scanning the call graph
for OpenMP runtime functions.

Depends on D102361

Reviewed By: jdoerfert

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

This patch adds a module level metadata flag indicating that the module
was compiled with the `-fopenmp` flag. This will make it easier for
passes like OpenMPOpt to determine if it should be run.

Reviewed By: jdoerfert

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

This causes failures on the big endian bootstrap bot.
Disabling this combine temporarily until I can get a proper fix.

rdar://76948312

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

When the default target arch isn't one that is supported as a
windows target, we want to set a suitable architecture (so that
Clang tests that run plain 'llvm-rc' succeed checks for e.g.
"#ifdef _WIN32" even for llvm builds that default to e.g. ppc64).

But if the default target architecture is usable, don't rewrite it.
(Rewriting it, by e.g. "T.setArch(T.getArch())", normalizes the
spelling of the architecture, e.g. changing i686 to i386. Such a
change can make clang unable to find the right sysroot.)

This can't, unfortunately, practically be tested very well because
it is entirely dependent on the default triple of the llvm build.

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

Modify the D13209 logic: for a script inside the sysroot, if an absolute path
does not exist, report an error instead of falling back to the path without the
sysroot prefix.

This matches GNU ld, which makes sense to me: we don't want to find an arbitrary
file in the host.

Reviewed By: ikudrin

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

Add support for the .reloc directive along the lines of
other back-ends.

This fixes a regression after https://reviews.llvm.org/D104080
was merged, since that patch presupposed support for .reloc.

Types should be defined in function scope instead of a local lexical scope. Field types should be defined inside in its parent type scope.

We were seeing a type defined in a local scope causing trouble to the dwarf emitter where a context is required to be a funciton scope, a namespace or a global scope.

Reviewed By: aprantl

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

Accidentally pushed old branches that did not include all the changes discussed in the PRs.

https://reviews.llvm.org/rGd43b23608ad664f02f56e965ca78916bde220950
https://reviews.llvm.org/rG86ad0af87054c3cccd68d32e103a6f1f6c6194c7

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

The type is no longer implicitly enumerated through the pointer
type.

Continuing to eliminate no-longer-needed uses of _LIBCPP_CXX03_LANG.

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

Shortcut to check for opaque pointers without a cast to PointerType.

A recent change that extended semantic analysis for actual arguments
that associate with procedure dummy arguments exposed some bugs in
regression test suites due to points of confusion in symbol table
handling in situations where a generic interface contains a specific
procedure of the same name.  When passing that name as an actual
argument, for example, it's necessary to take this possibility into
account because the symbol for the generic interface shadows the
symbol of the same name for the specific procedure, which is
what needs to be checked.  So add a small utility that bypasses
the symbol for a generic interface in this case, and use it
where needed.

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

This add as a fold of sub(0, splat(sub(0, x))) -> splat(x). This can
come up in the lowering of right shifts under AArch64, where we generate
a shift left of a negated number.

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

We don't need to have the compare output a value and then copy it
to FPSW for use by FNSTSW. Instead we can just have the compare
output Glue and glue the FNSTSW to it. InstrEmitter effectively
performed this optimization when emitting the Machine IR. Doing
it directly simplifies the codes and reduces the work in
InstrEmitter. There's no change in the machine IR at the end of
isel before and after this change.

`clang/test/utils/update_cc_test_checks/check-globals.test` from
9eaf0d12 broke at:

* <https://lab.llvm.org/buildbot/#/builders/110/builds/4415>
* <https://lab.llvm.org/buildbot/#/builders/5/builds/9076>

The problem is non-deterministic test order because the
`.lit_test_times.txt` from one run of a sample test suite affects the
other.

[libomptarget][amdgpu] Build openmp for two more targets

The 4800U APU is a gfx902 and the MI100 accelerator is a gfx908.
Both numbers are listed in ROCT topology.c

Reviewed By: jhuber6

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

Minor cleanup for follow-up patch.

[mlir:Async] Implement recursive async work splitting for scf.parallel operation (async-parallel-for pass)

Depends On D104780

Recursive work splitting instead of sequential async tasks submission gives ~20%-30% speedup in microbenchmarks.

Algorithm outline:
1. Collapse scf.parallel dimensions into a single dimension
2. Compute the block size for the parallel operations from the 1d problem size
3. Launch parallel tasks
4. Each parallel task reconstructs its own bounds in the original multi-dimensional iteration space
5. Each parallel task computes the original parallel operation body using scf.for loop nest

Reviewed By: herhut

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

Specify the `!async.group` size (the number of tokens that will be added to it) at construction time. `async.await_all` operation can potentially race with `async.execute` operations that keep updating the group, for this reason it is required to know upfront how many tokens will be added to the group.

Reviewed By: ftynse, herhut

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

If we have a umul.with.overflow where the multiply result is not used and one of the operands is a constant, we can perform the overflow check cheaper with a comparison then by performing the multiply and extracting the overflow flag.

(Noticed when looking at the conditions SCEV emits for overflow checks.)

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

This option is already supported by update_test_checks.py, but it can
also be useful in update_cc_test_checks.py.  For example, I'd like to
use it in OpenMP offload codegen tests to check global variables like
`.offload_maptypes*`.

Reviewed By: jdoerfert, arichardson, ggeorgakoudis

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

For each of the x.with.overflow variants, if only the overflow bit is consumed, we can generate a direct overflow comparison.  This precommits tests for each of the variants and tries to cover interesting cornercases.

This enables specifying operations that only support some element types for
unranked memrefs.

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

This change is NFC upstream. We pass in the loop's block to the kernel
rewriter explicitly, instead of assuming it's the loop's top block. This
change is made for downstream targets where this assumption doesn't hold.

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

With new pm becomes the default, the old-style test command becomes exactly the same as the new test command, i.e. the two commands are now redundant.
We should just delete the old command. (unless someone wants to add enable-new-pm=0 to all old commands.

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

This patch seems to be causing build errors, reverting it for now.

This reverts commit aeab9d95.

Do this by making opaque pointers a valid pointer element type,
for which we implicitly create an opaque pointer (moving the logic
from getPointerTo into PointerType::get).

We'll never create something like a "pointer to opaque pointer",
but accept it in the API, because a lot of code reasonably assumes
that you can create a pointer to pointer type.

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

See https://code.visualstudio.com/updates/v1_42#_implement-a-debug-adapter-inside-an-extension

Reviewed By: clayborg

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

There's no reason to use the weaker name-only analysis when we
have a function prototype to check (in fact, we probably should
not even have that name-only function exposed for general use,
but removing it requires auditing all of the callers).

The version of getLibFunc that takes a Function argument also
does some prototype checking to make sure the arguments/return
type match the expected signature of a real library call.

This is NFC-intended because the code in MemoryBuiltins does its
own function signature checking. For now, that means there may
be some redundancy in the checking, but that should not be above
the noise for compile-time. Ideally, we can move the checks to
a single location.

There's still a hole in the logic that allows the example in
https://llvm.org/PR50846 to cause a compiler crash.

To reflect that the size may be scalable, a TypeSize is returned
instead of an unsigned. In places where the result is used,
it currently relies on an implicit cast of TypeSize -> uint64_t,
which asserts that the type is not scalable.

This patch is NFC for fixed-width vectors.

Reviewed By: aemerson

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

The predicate definition didn't make sense anyway because it was defined
as being the opposite of what the name suggests.

Plus some minor related changes of the same nature.

In https://reviews.llvm.org/D103612, a definition of an instance of
`Fortran::parser::AnalyzedObjectsAsFortran` was moved (that object is
used in unparsing). That, in turn, introduced a dependency of the unit
tests on the `FortranEvaluate` library, which defines
`AnalyzedObjectsAsFortran`.

That dependency was missed in D103612 and has caused shared-library
builds to fail. I'm submitting this without a review, as it's rather
straightforward omission.

Reviewed By: aemerson

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

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