While one cannot of course statically initialize an allocatable component
of an instance of a derived type, its mere presence should not prevent
DATA initialization of the other nonallocatable components.  Semantics
was treating the existence of an allocatable component as a case of
"default initialization", which it is, but not one that should run
afoul of C877.  Add another Boolean argument to IsInitialized() to allow
for a more nuanced test.

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

When a jump table is recovered in postProcessIndirectBranches(),
successors for the containing basic block are added in random order.
Make the order deterministic.

Reviewed By: yota9

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

With XPLINK, dynamic stack allocations requires calling
a runtime function, which allocates the stack memory,
moves the register save area, and returns the new
stack pointer.

Reviewed By: uweigand

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

This change enables "abs" SDNodes selection by the node divergence.

Reviewed By: rampitec

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

Reviewed By: yota9, Amir

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

This reverts commit 43c2348c.

Buildbots are failing with an error on reading memprof testdata.
"Inputs/basic.profraw: profile uses zlib
compression but the profile reader was built without zlib support"

https://lab.llvm.org/buildbot/#/builders/16/builds/24490

Reviewed By: sivachandra, lntue

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

Add support for getenv as defined by the Open Group's "System Interface &
 Header" in https://pubs.opengroup.org/onlinepubs/7908799/xsh/getenv.html



getenv requires a standard way of accessing the environment,
so a pointer to the environment is added to the startup in crt1.
Consquently, this function is not usable on top of other libcs.

Added starts_with method to StringView. getenv function uses it.

Co-authored-by: Jeff Bailey <jeffbailey@google.com>

Reviewed By: sivachandra, rtenneti

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

When the runtime is initializing an instance of a derived type,
don't crash if an allocatable character component has deferred length.

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

The IR interpreter supports const operands to the `GetElementPtr` IR
instruction, so it should be able to evaluate expression without JIT.

Follow up to https://reviews.llvm.org/D113498

Reviewed By: shafik

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

This patch adds support for optional memory profile information to be
included with and indexed profile. The indexed profile header adds a new
field which points to the offset of the memory profile section (if
present) in the indexed profile. For users who do not utilize this
feature the only overhead is a 64-bit offset in the header.

The memory profile section contains (1) profile metadata describing the
information recorded for each entry (2) an on-disk hashtable containing
the profile records indexed via llvm::md5(function_name). We chose to
introduce a separate hash table instead of the existing one since the
indexing for the instrumented fdo hash table is based on a CFG hash
which itself is perturbed by memprof instrumentation.

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

While the contents of the profile are backwards compatible the header
itself is not. For example, when adding new fields to the header results
in significant issues. This change adds allows for portable
instantiation of the header across indexed format versions.

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

Use the macro based format to add a wrapper around the MemInfoBlock
when stored in the MemProfRecord. This wrapped block can then be
serialized/deserialized based on a schema specified by a list of enums.

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

This patch refactors out the MemInfoBlock definition into a macro based
header which can be included to generate enums, structus and code for
each field recorded by the memprof profiling runtime.

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

This reverts commit 744745ae.

I'm reverting this since this patch caused a build breakage.

https://lab.llvm.org/buildbot/#/builders/91/builds/3818

This reverts commit b099e1e5.

I'm reverting this since the head of the patch stack caused a build
breakage.

https://lab.llvm.org/buildbot/#/builders/91/builds/3818

This reverts commit bf5963bf.

I'm reverting this since the head of the patch stack caused a build
breakage.

https://lab.llvm.org/buildbot/#/builders/91/builds/3818

* While annoying, this is the only way to get C++ exception handling out of the happy path for normal iteration.
* Implements sq_length and sq_item for the sequence protocol (used for iteration, including list() construction).
* Implements mp_subscript for general use (i.e. foo[1] and foo[1:1]).
* For constructing a `list(op.results)`, this reduces the time from ~4-5us to ~1.5us on my machine (give or take measurement overhead) and eliminates C++ exceptions, which is a worthy goal in itself.
  * Compared to a baseline of similar construction of a three-integer list, which takes 450ns (might just be measuring function call overhead).
  * See issue discussed on the pybind side: https://github.com/pybind/pybind11/issues/2842

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

This avoids using an libc++ internal macro in our tests.

Reviewed By: #libc, philnik, ldionne

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

The current dectorator (@skipIfLinux) will skip the test if the lldb
platform is the linux platform, but the issue is with the OS that lldb
is running on, not the OS that lldb is debugging. Update the decorator
to skip the test if the host is Linux.

Thank you Ted Woodward for pointing this out.

```
always_inline foo() { }

bar () {

noinline foo();
}
```
We should prefer call site attribute over attribute on decl.

Related to https://reviews.llvm.org/D119061

Reviewed By: aeubanks

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

Recently we observed high memory pressure caused by clang during some parallel builds.
We discovered that we have several projects that have a large number of #define directives
in their TUs (on the order of millions), which caused huge memory consumption in clang due
to a lot of allocations for MacroInfo. We would like to reduce the memory overhead of
clang for a single #define to reduce the memory overhead for these files, to allow us to
reduce the memory pressure on the system during highly parallel builds. This change achieves
that by removing the SmallVector in MacroInfo and instead storing the tokens in an array
allocated using the bump pointer allocator, after all tokens are lexed.

The added unit test with 1000000 #define directives illustrates the problem. Prior to this
change, on arm64 macOS, clang's PP bump pointer allocator allocated 272007616 bytes, and
used roughly 272 bytes per #define. After this change, clang's PP bump pointer allocator
allocates 120002016 bytes, and uses only roughly 120 bytes per #define.

For an example test file that we have internally with 7.8 million #define directives, this
change produces the following improvement on arm64 macOS: Persistent allocation footprint for
this test case file as it's being compiled to LLVM IR went down 22% from 5.28 GB to 4.07 GB
and the total allocations went down 14% from 8.26 GB to 7.05 GB. Furthermore, this change
reduced the total number of allocations made by the system for this clang invocation from
1454853 to 133663, an order of magnitude improvement.

The recommit fixes the LLDB build failure.

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

Reported by scan-build.

Rationale:
empty line between main include for this file
moved include that actually defines code into right section

Note that this revision started as breaking up ops/attrs even more
(for bug https://github.com/llvm/llvm-project/issues/52748), but due
the the connection in Dialect.initalize(), this cannot be split further).
All heavy lifting refactoring was already done by River in previous cleanup.

Reviewed By: bixia

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

Also modified operator[] to return a reference to the array element.

Reviewed By: lntue

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

With XPLINK, a no-op with information about the call type is emitted
after each call instruction. Centralizing it has the advantage that it is
easy to document all cases, and it makes it easier to extend it later
(e.g. dynamic stack allocation, 32 bit mode).
Also add a test checking the call types emitted so far.

Reviewed By: uweigand

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

Currently the fsub optimizations in InstSimplify don't know how to fold X
- +0.0 to X when using the constrained intrinsics. This adds the support.

This review is split out from D107285.

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

Adds a pointer type to EmitC. The emission of pointers is so far only
possible by using the `emitc.opaque` type

Co-authored-by: Simon Camphausen <simon.camphausen@iml.fraunhofer.de>

Reviewed By: jpienaar

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

Replace forms of `assertTrue(err.Success())` with `assertSuccess(err)` (added in D82759).

* `assertSuccess` prints out the error's message
* `assertSuccess` expresses explicit higher level semantics, both to the reader and for test failure output
* `assertSuccess` seems not to be well known, using it where possible will help spread knowledge
* `assertSuccess` statements are more succinct

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

when the function declaration's return type is already invalid for
some reason. This is relevant to https://github.com/llvm/llvm-project/issues/49188
because another way that the declaration's return type could become
invalid is that it might be `C auto` where `C<void>` is false.

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

Reviewed as part of D119094.

Depending on toolchain and ABI, a target might not output DWARF unwind tables by default.
Run the test for a target with a known behaviour, test coverage is not reduced.

Reviewed By: dmgreen

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

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