Based on https://reviews.llvm.org/D132312
Dependes on https://reviews.llvm.org/D132312

Reviewed By: #libc, Mordante, philnik

Spies: philnik, Mordante, yaxunl, libcxx-commits

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

Before this change, we call getUnderlyingObject on each separate_storage
operand on every alias() call (potentially requiring lots of pointer
chasing). Instead, we rewrite the assumptions in instcombine to do this
pointer-chasing once.

We still leave the getUnderlyingObject calls in alias(), just expecting
them to be no-ops much of the time. This is relatively fast (just a
couple dyn_casts with no pointer chasing) and avoids making alias
analysis results depend on whether or not instcombine has been run.

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

This adds more test cases with loop guards involving min/max
and which should be covered by ScalarEvolution::applyLoopGuards.

This factors out two utilities used with RewriteMap in applyLoopGuards:
 - AddRewrite, which puts a rewrite rule in the map and if needed registers
   the rewrite in the list of rewritten expressions,
 - GetMaybeRewritten, which checks whether an expression has already been
   rewritten, and if so, returns the rewrite. Otherwise, returns the given
   expression.

This may be needed when adding new rewrite rules as not to copy-paste this
code.

This reverts commit 8aa9ab33.

Reverting due to compile-time regressions as pointed out in
 https://reviews.llvm.org/D145051#4166656
E.g.
 "In particular tramp3d-v4 with debuginfo regressed by 15%."

Adds f16 and v2f16 ldg builtins and relevant tests.

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

Reviewed By: nikic

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

This reverts commit 8a023fed.

The machine is back online.

To make legalization easier, the operands and outputs have the same size for
these ISD Nodes. When legalizing the results in PromoteIntegerResult the operands
are legalized to the same size as the outputs.
The ISD Node has two output/results, therefore the legalizing functions update
both results/outputs.

Reviewed By: paulwalker-arm

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

The search for temporal divergence needs to determine a dominance frontier
defined for a cycle. The implementation uses a temporary vector to store a set
of newly discovered successors. Failing to uniqify the elements in this vector
causes a very large regression in compile time due to an exponential number of
redundant visits.

This fixes github issue #61123

Reviewed By: foad

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

The tests can fail if working directory where the tests were launched
has a `error` substring in its path.

Reviewed By: jhenderson, foad

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

Fixes #61094

Recommit [C++20] [Modules] Trying to compare the trailing require clause from the primary template function

Close https://github.com/llvm/llvm-project/issues/60890.

For the following example:

```
export module a;

export template<typename T>
struct a {
	friend void aa(a) requires(true) {
	}
};
```

```
export module b;

import a;

struct b {
	a<int> m;
};
```

```
export module c;

import a;

struct c {
	void f() const {
		aa(a<int>());
	}
};
```

```
import a;
import b;
import c;

void d() {
	aa(a<int>());
}
```

The current clang will reject this incorrectly. The reason is that the
require clause  will be replaced with the evaluated version
(https://github.com/llvm/llvm-project/blob/efae3174f09560353fb0f3d528bcbffe060d5438/clang/lib/Sema/SemaConcept.cpp#L664-L665).
In module 'b', the friend function is instantiated but not used so the
require clause of the friend function is `(true)`. However, in module
'c', the friend function is used so the require clause is `true`. So
deserializer classify these two function to two different functions
instead of one. Then here is the bug report.

The proposed solution is to try to compare the trailing require clause
of the primary template when performing ODR checking.

Reviewed By: erichkeane

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

The machine hosting these agents will be down
for maintenance today.

We (Linaro) will remove this once the agents are back online.

This reverts commit fe758254.

This change was causing several buildbot failures:
- https://lab.llvm.org/buildbot/#/builders/38/builds/10105
- https://lab.llvm.org/buildbot/#/builders/192/builds/562
- https://lab.llvm.org/buildbot/#/builders/109/builds/58893
- https://lab.llvm.org/buildbot/#/builders/16/builds/44360
- https://lab.llvm.org/buildbot/#/builders/247/builds/2095
- https://lab.llvm.org/buildbot/#/builders/196/builds/27236
- https://lab.llvm.org/buildbot/#/builders/54/builds/3714

This is a fix for a problem when multiple template
specializations are created by ASTImporter for the
same specialization. The problem happens if a
TemplateName is imported that points to a template
delcaration (for a template template argument)
(specialization) that has multiple instances in the
declaration chain. If two TemplateName objects contain
different pointers to a template specialization,
these TemplateName objects will have different checksum
even if they point into the same declaration chain.
The problem is fixed if the canonical declaration is used.

Reviewed By: vabridgers, donat.nagy

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

This could improve user experience for stack unwinding, and also this is
enabled by default by X86 and AArch64 and RISC-V GCC.

Reviewed By: luismarques, MaskRay

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

Based on Richard's suggestion in D126341:
`If we can actually describe a rule that we provide for initialization
order of instantiated variables, and we can easily implement that rule
and be confident we won't want to substantially weaken it later, and we
can thereby assure our users that we will satisfy that rule, then I
think that could be interesting, but anything less than that doesn't
seem worthwhile to me.`

I'm giving it try here. IMHO the implementation is pretty simple and
does not change behavior for unrelated constructs like the timing when
instantiated variables are passed to CodeGen.

This is based on the same ordering guarantee needed for inline variables D127233.
To provide this guarantee, we also need to
emit DeferredDeclsToEmit in the DFS order. https://github.com/llvm/llvm-project/commit/e5df59ff78faebd897e81907606ce6074aac0df6
originally supported this but it is not exactly DFS order for cases like
the one in cwg362. For the example of Fib<5>, it triggers the instantiation
of Fib<4> and Fib<3>. However, due to the way GlobalEagerInstantiationScope
is implemented, Fib<4> does not actually trigger Fib<3> instantiation
since it is already triggered by Fib<5>. This breaks the guarantee.

This patch makes sure DeferredDeclsToEmit is emitted in DFS order by moving
DeferredDeclsToEmit storage from the call stack to an explicit stack-like
data structure. Then the DFS order could be enforced.

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

Without deferencing it just prints the value of the pointer which
isn't meaningful. Dereferencing prints the operand.

The entrypoint has been added to the various entrypoint lists. The libc
code style doc has been updated with information on how errno should be
set from the libc runtime code.

Reviewed By: lntue

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

We now limit ADCE to only remove debug intrinsics if it does something else
that would invalidate cached analyses anyway.
As we've seen in
 https://github.com/llvm/llvm-project/issues/58285
throwing away cached analysis info when only debug instructions are removed
can lead to different code when debug info is present or not present.

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

Close https://github.com/llvm/llvm-project/issues/60824

The form -fmodule-file=<path-to-BMI> will load modules eagerly and the
form -fmodule-file=<module-name>=<path-to-BMI> will load modules lazily.
The inconsistency adds many additional burdens to the implementations.
And the inconsistency looks not helpful and necessary neither. So I want
to deprecate the form -fmodule-file=<path-to-BMI> for named modules.
This is pretty helpful for us (the developers).

Does this change make any regression from the perspective of the users?

To be honest, yes. But I think such regression is acceptable. Here is
the example:

```
// M.cppm
export module M;
export int m = 5;

// N.cpp
// import M; // woops, we forgot to import M.
int n = m;
```

In the original version, the compiler can diagnose the users to import
`M` since the compiler have already imported M. But in the later style,
the compiler can only say "unknown identifier `m`".

But I think such regression doesn't make a deal since it only works if
the user put `-fmodule-file=M.pcm` in the command line. But how can the
user put `-fmodule-file=M.pcm` in the command line without `import M;`?
Especially currently such options are generated by build systems. And
the build systems will only generate the command line from the source
file.

So I think this change is pretty pretty helpful for developers and
almost innocent for users and we should accept this one.

I'll add the release notes and edit the document after we land this.

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

Some workflows can generate large GSYM files and sharding GSYM files into segments can help some performant workflows that can take advantage of smaller GSYM files. This patch add a new --segment-size option to llvm-gsymutil. This option can specify a rough size in bytes of how large each segment should be.

Segmented GSYM files contain only the strings and files that are needed for the FunctionInfo objects that are added to each shard. The output file path gets the first address of the first contained function info appended as a suffix to the filename. If a base address of an image is set in the GsymCreator, then all segments will use this same base address which allows lookups for symbolication to happen correctly when the image has been slid in memory.

Code has been addeed to refactor and re-use methods within the GsymCreator to allow for segments to be created easily and tested.

Example of segmenting GSYM files:

$ llvm-gsymutil --convert llvm-gsymutil.dSYM -o llvm-gsymutil.gsym --segment-size 10485760
$ ls -l llvm-gsymutil.gsym-*
-rw-r--r--  1 gclayton  staff  10485839 Feb  9 10:45 llvm-gsymutil.gsym-0x1000030c0
-rw-r--r--  1 gclayton  staff  10485765 Feb  9 10:45 llvm-gsymutil.gsym-0x100668888
-rw-r--r--  1 gclayton  staff  10485881 Feb  9 10:45 llvm-gsymutil.gsym-0x100c948b8
-rw-r--r--  1 gclayton  staff  10485954 Feb  9 10:45 llvm-gsymutil.gsym-0x101659e70
-rw-r--r--  1 gclayton  staff  10485792 Feb  9 10:45 llvm-gsymutil.gsym-0x1022b1dc0
-rw-r--r--  1 gclayton  staff  10485889 Feb  9 10:45 llvm-gsymutil.gsym-0x102a18b10
-rw-r--r--  1 gclayton  staff  10485893 Feb  9 10:45 llvm-gsymutil.gsym-0x1030b05d0
-rw-r--r--  1 gclayton  staff  10485802 Feb  9 10:45 llvm-gsymutil.gsym-0x1037caaac
-rw-r--r--  1 gclayton  staff  10485781 Feb  9 10:45 llvm-gsymutil.gsym-0x103e767a0
-rw-r--r--  1 gclayton  staff  10485832 Feb  9 10:45 llvm-gsymutil.gsym-0x10452d0d4
-rw-r--r--  1 gclayton  staff  10485782 Feb  9 10:45 llvm-gsymutil.gsym-0x104b93310
-rw-r--r--  1 gclayton  staff   6255785 Feb  9 10:45 llvm-gsymutil.gsym-0x10526bf34

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

The input parameter IsByValArg to isEligibleForTCO() is false in all
cases, so it is considered redundant and should be removed.

Reviewed By: shchenz

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

[C++20] [Modules] Make TheImplicitGlobalModuleFragment and TheExportedImplicitGlobalModuleFragment to be useable modules

The unexported language linkage become unvisible to the current module
unit after the previous commit bf52ead2. This patch fixes the issue.

Close https://github.com/llvm/llvm-project/issues/60405

See the discussion in the above link for the background.

What the patch does:
- Rename `Module::ModuleKind::GlobalModuleFragment` to
  `Module::ModuleKind::ExplicitGlobalModuleFragment`.
- Add another module kind `ImplicitGlobalModuleFragment` to
  `ModuleKind`.
- Create an implicit global module fragment for the language linkage
  declarations inside a module purview.
    - If the language linkage lives inside the scope of an export decl,
      the created modules is marked as exported to outer modules.
- In fact, Sema will only create at most 2 implicit global module
  fragments to avoid creating a lot of unnecessary modules in the edging
case.

Reviewed By: iains

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

Currently, there are bugs in Clang's intrinsics for type traits when
handling Objective-C++ `id` (e.g. in `add_pointer`). As a temporary
workaround, don't use these intrinsics in the Objective-C++ mode.

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

Use `value_or` instead of `value` for checking minor versions in
`ArchInfo::implies`.

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

Only generate the second def file when necessary (native Windows import
library builds).
Properly clean up .def file artifacts.
Reduce the re-generated import library build artifacts to the minimum.
Refactor the import library related portions of the script for clarity.

Tested with MSVC and MinWG/gcc12.0

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

This reverts commit 41e31466
due to a build failure on Windows.

When a global procedure has no explicit interface, emit warnings
when its references are inconsistent implicit procedure interfaces.

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

These files were added in 97dcbea6 but
it looks like they are missing header guards. This breaks module builds.

Move MaxDepth into the lambda, since it is not needed outside. This
fixes some compilers that complain about missing capture:

  error C3493: 'MaxDepth' cannot be implicitly captured because no
  default capture mode has been specified

Fixes: f693932f ("[SelectionDAG] Transitively copy NodeExtraInfo on RAUW")

GISel's CSE mechanism lazily inserts instructions into the CSE List
to improve on efficiency as well as efficacy of CSE
(for allowing partially built instructions to be fully built).

There's unfortunately a mutual recursion via
 `handleRecordedInsts -> handleRecordedInst -> insertNode-> handleRecordedInsts`.

So this change simply records that we're already draining this list so we can just bail out on the recursion.

No changes to codegen are expected as we're still draining/handling the temporary
list via pop_back and we should get the same sequence of instructions
whether we call pop_back in a loop at the top level or recursive.

https://reviews.llvm.org/D145006

reviewed by: dsanders

Switch use of errno in src/time and test/src/time to libc_errno.

Reviewed By: sivachandra

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

Revert while I investigate two CI bot failures;
the more important is the lldb-arm-ubuntu where
the FixAddress is removing the 0th bit so we're
adding the `actual=` decorator on a string pointer,

```
Got output:
(char *) strptr = 0x00400817 (actual=0x400816) ptr = [{ },{H}]
```

in TestDataFormatterSmartArray.py line 229.

This reverts commit 4d635be2.

I also removed two runlines which added no additional coverage.  No test in the file has both loads and stores, thus the two configurations duplicate the disabled configuration.