On AIX, this test generates an XCOFF file and hits "unknown binary format" assertion in llvm-nm. This patch specifies the triple to mitigate this issue.

Reviewed By: steven_wu

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

Need to postpone anlysis of the ranged for loops till the actual
instantiation to avoid erroneous emission of error messages.

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

This change extends the current logic for inferring readonly and readnone argument attributes to also infer writeonly.

This change is deliberately minimal; there's a couple of areas for follow up.
* I left out all call handling and thus any benefit from the SCC walk. When examining the test changes, I realized the existing code is imprecise, and am going to fix that in it's own revision before adding in the writeonly handling. (Mostly because updating the tests is hard when I, the human, can't figure out whether the result is correct.)
* I left out handling for storing a value (as opposed to storing to a pointer). This should benefit readonly/readnone as well, and applies to a bunch of other instructions. Seemed worth having as a separate review.

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

Need to postpone analysis for addressable lvalue in a depend clause with
iterators, otherwise the incorrect error message is emitted.

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

Provides an implementation of `HTTPClient` that wraps libcurl.

Reviewed By: dblaikie

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

This reverts commit 8b646f21.

Reviewed By: kstoimenov

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

update the namspace comments in include/

Reviewed By: ldionne, #libc

Spies: smeenai, libcxx-commits

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

This is a continuation of D109860 and D109903.

An important challenge for profile inference is caused by the fact that the
sample profile is collected on a fully optimized binary, while the block and
edge frequencies are consumed on an early stage of the compilation that operates
with a non-optimized IR. As a result, some of the basic blocks may not have
associated sample counts, and it is up to the algorithm to deduce missing
frequencies. The problem is illustrated in the figure where three basic
blocks are not present in the optimized binary and hence, receive no samples
during profiling.

We found that it is beneficial to treat all such blocks equally. Otherwise the
compiler may decide that some blocks are “cold” and apply undesirable
optimizations (e.g., hot-cold splitting) regressing the performance. Therefore,
we want to distribute the counts evenly along the blocks with missing samples.
This is achieved by a post-processing step that identifies "dangling" subgraphs
consisting of basic blocks with no sampled counts; once the subgraphs are
found, we rebalance the flow so as every branch probability is 50:50 within the
subgraphs.

Our experiments indicate up to 1% performance win using the optimization on
some binaries and a significant improvement in the quality of profile counts
(when compared to ground-truth instrumentation-based counts)

{F19093045}

Reviewed By: hoy

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

Make users aware what to do with ld.lld 13.0.0 / GNU ld<2015-10 --gc-sections
behavior.

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

This reverts commit 25eb7fa0.

Previous buildbot failures appear to have been a fluke from a dirty
build.

Reviewed By: morehouse

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

This code and cmake was removed in https://reviews.llvm.org/D114842

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

The goal is to identify the bot and try to fix it.

SetSoftRssLimitExceededCallback is AsanInitInternal as I assume
that only MaybeStartBackgroudThread needs to be delayed to constructors.
Later I want to move MaybeStartBackgroudThread call into sanitizer_common.

If it needs to be reverted please provide to more info, like bot, or details about setup.

Reviewed By: kstoimenov

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

Seems better to rely on the existing formatting, makes the output
smaller/simpler - this is consistent with libstdc++'s std::string_view
pretty printing too.

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

Updates Bazel files for 9e355252

During the llvm round table it was generally agreed that the newer macho
lld implementation is feature complete enough to replace the old
implementation entirely. This will reduce confusion for new users who
aren't aware of the history.

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

This is a continuation of D109860.

Traditional flow-based algorithms cannot guarantee that the resulting edge
frequencies correspond to a *connected* flow in the control-flow graph. For
example, for an instance in the attached figure, a flow-based (or any other)
inference algorithm may produce an output in which the hot loop is disconnected
from the entry block (refer to the rightmost graph in the figure). Furthermore,
creating a connected minimum-cost maximum flow is a computationally NP-hard
problem. Hence, we apply a post-processing adjustments to the computed flow
by connecting all isolated flow components ("islands").

This feature helps to keep all blocks with sample counts connected and results
in significant performance wins for some binaries.
{F19077343}

Reviewed By: hoy

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

Reviewed By: pifon2a

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

If the extractelement instruction is used multiple times in the
different tree entries (either vectorized, or gathered), need to
compensate the scalar cost of such instructions. They are completely
removed if all users are part of the tree but we need to compensate the
cost only once for each instruction.

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