In review for https://reviews.llvm.org/D146278, @vzakhari asked to
separate -emit-fir and -emit-hlfir. This will allow FIR to be easily
outputted after the HLFIR passes have been run.

The new semantics are as follows:

| Action      | -flang-experimental-hlfir? | Result |
| =========== | ========================== | =============================== |
| -emit-hlfir | N                          | Outputs HLFIR                   |
| -emit-hlfir | Y                          | Outputs HLFIR                   |
| -emit-fir   | N                          | Outputs FIR, using old lowering |
| -emit-fir   | Y                          | Outputs FIR, lowering via HLFIR |

A patch for bbc will follow.

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

A CU can have only one function so CU will have low_pc/high_pc. If this funciton
is GCed by LLD low_pc will become 0x0, and BOLT can't map this to output. We
kind of were getting away with it in monolithic DWARF, but with split DWARF
there is only skeleton CU, so we end up with rnglist with header and array, but
no body. This caused LLDB to report an error.

Reviewed By: maksfb

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

Sometimes an developer would like to have more control over cmov vs branch. We have unpredictable metadata in LLVM IR, but currently it is ignored by X86 backend. Propagate this metadata and avoid cmov->branch conversion in X86CmovConversion for cmov with this metadata.

Example:

```
int MaxIndex(int n, int *a) {
    int t = 0;
    for (int i = 1; i < n; i++) {
        // cmov is converted to branch by X86CmovConversion
        if (a[i] > a[t]) t = i;
    }
    return t;
}

int MaxIndex2(int n, int *a) {
    int t = 0;
    for (int i = 1; i < n; i++) {
        // cmov is preserved
        if (__builtin_unpredictable(a[i] > a[t])) t = i;
    }
    return t;
}
```

Reviewed By: nikic

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

This doc was written 4 years ago, some refresh in the example was
overdue I suspect.

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

Fixing broken test in D140524 "Flang implementation for COMPILER_VERSION and COMPILER_OPTIONS intrinsics".

Despite me being convinced that the use of divide didn't produce any
divide instructions, it does in fact add more instructions than using
a plain shift operation.

This patch simply changes the divide to a shift right, with an
assert to check that the "divisor" is a power of two.

Reviewed By: kiranchandramohan, tblah

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

Provide an example of how to use this extension and more importantly,
document that cleanup functions are run in reverse nested order.

Reviewed By: erichkeane

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

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

Matches behaviour from tsan_interceptors_posix. This is covered by sanitizer_common/TestCases/malloc_hook.cpp (which is currently failing on darwin)
I've tested it on an arm-based Mac & also compiled to x86_64 on it.

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

After 572cfa3f, isUniform now checks VF based uniformity instead of
just invariance as before.

As follow-up cleanup suggested in D148841, separate the invariance check
out and update callers that currently check only for invariance.

This also moves the implementation of isUniform from LoopAccessAnalysis
to LoopVectorizationLegality, as LoopAccesAnalysis doesn't use the more
general isUniform.

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

Emit a 4-byte alignment after the .arm directive and a 2-byte alignment
after the .thumb directive. The new behavior matches GNU assembler.

Fixes #53386

Reviewed By: MaskRay

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

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

This patch removes some deprecated uses of `{File,Directory}Entry::getName()`. No functional change indended.

Depends on D151853.

Reviewed By: benlangmuir

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

DNBGetDeploymentInfo was calling GetPlatformString w/o checking that
the load command it was processing actually provided a platform string.
That caused a bunch of worrisome looking error messages in the debugserver
log output.

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

Add some more tests of what exceptions we accept and don't accept.

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

This reverts commit 731f9ac6.

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

Now that we've converted libcxxabi and llvm Demangle to use
std::string_view, this code no longer has any users. Bye bye!

Reviewed By: #libc_abi, phosek, MaskRay

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

This mimics the `ModuleMap` API and enables D151854, where the `AllowCreation = true` function needs `FileEntryRef` but `AllowCreation = false` functions is happy with plain `FileEntry`. No functional change intended.

Reviewed By: benlangmuir

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

This patch removes path hackery from `ModuleMapCallbacks` by adopting `FileEntryRef`. No functional change intended.

Reviewed By: benlangmuir

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

On llvm.org and all downstream forks that I'm aware of, SignalCodes are
always created from C string literals. They are never compared to
anything so they take up space in the ConstString StringPool for no
tangible benefit.

I've changed the type here to `const llvm::StringLiteral` instead of
using a `StringRef` or a `const char *` to express intent -- These
strings come from constant data whose lifetime is directly tied to that
of the running process (and are thus safe to store).

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

This reverts commit 0a762ec1.

Some CPUs enable fp64 by default (such as cortex-m7). When specifying a
single-precision fpu with them like -mfpu=fpv5-sp-d16, the fp64 feature will
be disabled, but fpreg64 will not. We need to disable them both correctly under
clang in order for the backend to be able to use the reliably. In the meantime
this reverts 0a762ec1 until that issue is fixed.

D144654 made it so that we warn on any defining or undefining of
builtin macros. However the C and C++ standards only forbid the
defining or undefining of macros defined in the language standard
itself, but clang defines more macros than those and warning on those
may not be helpful.

Resolve this by only warning if the builtin macro name is the name of
a macro defined by the language. This is done in a way that removes
some of the existing checks, as those were made redundant by
restricting the warning in this way.

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

This revision implements the Fortran intrinsic procedures COMPILER_VERSION and COMPILER_OPTIONS from the iso_fortran_env module.
To be able to set the COMPILER_OPTIONS string according to the original compiler driver invocation, a string is passed to the frontend driver using the environment variable FLANG_COMPILER_OPTIONS_STRING, for lack of a better mechanism.

Fixes #59233

Reviewed By: awarzynski

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

Starting with the SDKs provided with Xcode 14.3, this library no longer
exists. Before this change this results in an opaque linker error in the
case that your deployment target is low enough that this library is
added. This produces a more useful error message in that case.

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

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

Restructures the combined index based promotion and internalization
decision code so that it is a bit easier to follow. This is in
preparation for a bugfix to this code that will modify one part of the
logic.

Reviewed By: #libc, philnik

Spies: libcxx-commits

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits, miyuki

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

The SCCPSolver is using a structure (AnalysisResultsForFn) where it keeps
pointers to various analyses needed by the IPSCCP pass. These analyses are
requested all at the same time, which can become problematic in some cases.
For example one could be retrieved via getCachedAnalysis() prior to the
actual execution of the analysis. In more detail:

The IPSCCP pass uses a DomTreeUpdater to preserve the PostDominatorTree
in case the PostDominatorTreeAnalysis had run before IPSCCP. Starting with
commit 1b123204 the IPSCCP pass may use BlockFrequencyAnalysis for
some functions in the module. As a result, the PostDominatorTreeAnalysis
may not run until the BlockFrequencyAnalysis has run, since the latter
analysis depends on the former. Currently, we setup the DomTreeUpdater
using getCachedAnalysis to retrieve a PostDominatorTree. This happens
before BlockFrequencyAnalysis has run, therefore the cached analysis can
become invalid by the time we use it.

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

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

This new channel data type was added in OpenCL C 3.0.

This replaces some uses of internal libc++ macros with the equivalent
macro from "test_macros.h".

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

This removes the need for contributors to do some manual steps
when adding a new public header.

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

If the step is not loop-invariant, we cannot create a modified AddRec,
as the start needs to be loop-invariant. Mark those cases as
CannotAnalyze and bail out, to fix a crash.