We already have an experimental option to tune loop alignment. Its impact
is very wide (and there is a suspicion that it's not always profitable). We want
to have something more narrow to play with. This patch adds similar option that
overrides preferred alignment for innermost loops. This is for experimental
purposes, default values do not change the existing behavior.

Differential Revision: https://reviews.llvm.org/D94895
Reviewed By: pengfei

Define vlsseg intrinsics and pseudo instructions. Lower vlsseg
intrinsics to pseudo instructions in RISCVDAGToDAGISel.

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

Define vlsseg intrinsics and pseudo instructions. Lower vlsseg intrinsics
to pseudo instructions in RISCVDAGToDAGISel.

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

Define vsseg intrinsics and pseudo instructions. Lower vsseg intrinsics
to pseudo instructions in RISCVDAGToDAGISel.

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

Upstream the eCore_arm_arm64e enum value in ArchSpec. All the other
arm64e triple changes already landed in LLVM.

Differential revision: https://reviews.llvm.org/D95110

This should minimize change in a future patch.

The modification time in the debug map is expressed using second
precision, while the modification time returned by the filesystem could
be more precise. Avoid spurious warnings about timestamp mismatches by
truncating the modification time reported by the system to seconds.

Copy paste error, but the test still built on macOS.  Weird.
It failed on debian linux with an error about -fno-limit-debug-info
not being a supported flag???  Not sure how this goof would cause
that error, but let's see if it did...

Reviewed-by: eugenis

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

If they occurred before the constructor that used them, we would refuse to
set the breakpoint because we thought they were crossing function boundaries.

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

Use `clang_cc1` test for `declare_target_device_only_compilation.cpp`

Reviewed By: echristo

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

This is the test case for D95086 with worse result.

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

I attempted to write a test case for this, but the situations in which the kind is used for RegionDirective and ResultsDirective have zero overlap; meaning that there isn't a situation in which sharing the kind creates a conflict.

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

Having this function in a public scope is helpful to register dialects that are
defined at runtime, and thus that need a runtime-defined TypeID.

Also, a similar function in DialectRegistry, insert(TypeID, StringRef, ...), has
a public scope.

Reviewed By: mehdi_amini

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

An `unrealized_conversion_cast` operation represents an unrealized conversion
from one set of types to another, that is used to enable the inter-mixing of
different type systems. This operation should not be attributed any special
representational or execution semantics, and is generally only intended to be
used to satisfy the temporary intermixing of type systems during the conversion
of one type system to another.

This operation was discussed in the following RFC(and ODM):

https://llvm.discourse.group/t/open-meeting-1-14-dialect-conversion-and-type-conversion-the-question-of-cast-operations/

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

A cast-like operation is one that converts from a set of input types to a set of output types. The arity of the inputs may be from 0-N, whereas the arity of the outputs may be anything from 1-N. Cast-like operations are removable in cases where they produce a "no-op", i.e when the input types and output types match 1-1.

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

Based on feedback in https://reviews.llvm.org/D93433.

Reviewed By: dblaikie

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

I missed the MPFR tests in my previous commit. They have now been fixed
to not fail the prefix check in the test macro.

Summary:
Having a consistent prefix makes selecting all of the llvm libc tests
easier on any platform that is also using the gtest framework.
This also modifies the TEST and TEST_F macros to enforce this change
moving forward.

Reviewers: sivachandra

Subscribers:

Reviewed By: jdoerfert

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

Previously we only matched (and (shl X, C1), 0xffffffff << C1)
which matches the InstCombine canonicalization order. But its
possible to see (shl (and X, 0xffffffff), C1) if the pattern
is introduced in SelectionDAG. For example, through expansion of
a GEP.

This is closer to the kind of code that these intrinsics are
targeted at. Note we fail to match slliu.w here because our pattern
looks for (and (shl X, C1), 0xffffffff << C1) rather than
(shl (and X, 0xffffffff), C1). I'll fix this in a follow up
commit.

This reverts commit 7dd19885.

ASAN issue.

Rationale:
Since I made the argument that metadata helps with extra
verification checks, I better actually do that ;-)

Reviewed By: penpornk

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

All of these families were claiming to be a73 based, which was causing
-mcpu/mtune=native to never use the newer features available to these
cores.

Goes through each and bumps the individual cores to their respective Big
counterparts. Since this code path doesn't support big.little detection,
there was already a precedent set with the Qualcomm line to choose the
big cores only.

Adds a comment on each line for the product's name that the part number
refers to. Confirmed on-device and through Linux header naming
convections.

Additionally newer SoCs mix CPU implementer parts from multiple
implementers. Both 0x41 (ARM) and 0x51 (Qualcomm) in the Snapdragon case

This was causing a desync in information where the scan at the start to
find the implementer would mismatch the part scan later on.
Now scan for both implementer and part at the start so these stay in
sync.

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

Makefile.rules: Avoid redundant .d generation (make restart) and inline archive rule to the only test

Take an example when `CXX_SOURCES` is main.cpp.

main.d is an included file. make will rebuild main.d, re-executes itself [1] to read
in the new main.d file, then rebuild main.o, finally link main.o into a.out.
main.cpp is parsed twice in this process.

This patch merges .d generation into .o generation [2], writes explicit rules
for .c/.m and deletes suffix rules for %.m and %.o. Since a target can be
satisfied by either of .c/.cpp/.m/.mm, we use multiple pattern rules. The
rule with the prerequisite (with VPATH considered) satisfied is used [3].

Since suffix rules are disabled, the implicit rule for archive member targets is
no long available [4]. Rewrite, simplify the archive rule and inline it into the
only test `test/API/functionalities/archives/Makefile`.

[1]: https://www.gnu.org/software/make/manual/html_node/Remaking-Makefiles.html
[2]: http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/
[3]: https://www.gnu.org/software/make/manual/html_node/Pattern-Match.html
[4]: https://www.gnu.org/software/make/manual/html_node/Archive-Update.html

ObjC/ObjCXX tests only run on macOS. I don't have testing environment.  Hope
someone can do it for me.

Reviewed By: JDevlieghere

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

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

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

This reverts commit d97f776b.

The original problem was due to build failures in shared lib builds. D95079
moved ImportedFunctionsInliningStatistics under Analysis, unblocking
this.

Resumed coroutine potentially can deallocate the token/value/group and destroy the mutex before the std::unique_ptr destructor.

Reviewed By: mehdi_amini

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

This is related to D94982. We want to call these APIs from the Analysis
component, so we can't leave them under Transforms.

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

It's possible to  declare deferred shape array using the POINTER
statement, for example:

  POINTER :: var(:)

When analyzing POINTER declarations, we were not capturing the array
specification information, if present.  I fixed this by changing the
"Post" function for "parser::PointerDecl" to check to see if the
declaration contained a "DeferredShapeSpecList".  In such cases, I
analyzed the shape and used to information to declare an "ObjectEntity"
that contains the shape information rather than an "UnknownEntity".

I also added a couple of small tests that fail to compile without these
changes.

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

Once we switch to build deviceRTLs with OpenMP, primitives and CUDA
intrinsics cannot be used directly anymore because `__device__` is not recognized
by OpenMP compiler. To avoid involving all CUDA internal headers we had in `clang`,
we forward declared these functions. Eventually they will be transformed into
right LLVM instrinsics.

Reviewed By: JonChesterfield

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

This change adds function types to further differentiate between
FUNC_IDs in -gline-tables-only.

Size increase of object files in clang are
Before: 917990 kb
After:  999312 kb

Bug: https://bugs.llvm.org/show_bug.cgi?id=48432

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

* IsArrayElement() needs another option to control whether it
  should ignore trailing component references.
* Add IsObjectPointer().
* Add const Scope& variants of IsFunction() and IsProcedure().
* Make TypeAndShape::Characterize() work with procedure bindings.
* Handle CHARACTER length in MeasureSizeInBytes().
* Fine-tune FindExternallyVisibleObject()'s handling of dummy arguments
  to conform with Fortran 2018: only INTENT(IN) and dummy pointers
  in pure functions signify; update two tests accordingly.

Also: resolve some stylistic inconsistencies and add a missing
"const" in the expression traversal template framework.

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

This may simplify the composition of patterns but is otherwise NFC.