The rule was added in 2014 to support -stdlib=libc++ and -lc++ without
specifying -L, when D.Dir is not a well-known system library directory like
/usr/lib /usr/lib64. This rule turns out to get in the way with (-m32 for
64-bit clang) or (-m64 for 32-bit clang) for Gentoo :
https://github.com/llvm/llvm-project/issues/54515

Nowadays LLVM_ENABLE_RUNTIMES is the only recommended way building libc++ and
LLVM_ENABLE_PROJECTS=libc++ is deprecated. LLVM_ENABLE_RUNTIMES builds libc++
in D.Dir+"/../lib/${triple}/". The rule is unneeded. Also reverts D108286.

Gentoo uses a modified LLVM_ENABLE_RUNTIMES that installs libc++.so in
well-known paths like /usr/lib64 and /usr/lib which are already covered by
nearby search paths.

Implication: if a downstream package needs something like -lLLVM-15git and uses
libLLVM-15git.so not in a well-known path, it needs to supply -L
D.Dir+"/../lib" explicitly (e.g. via LLVMConfig.cmake), instead of relying on
the previous default search path.

Reviewed By: mgorny

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

This reverts commit b9fd8f34 as it
accidentally contained a unit test change that is not finished (and
unrelated).

Make the test more robust to slightly different metadata numbering by
using a pattern instead of hard coding the ids.

This patch adds a helper method to determine if a nonvirtual base has an entry in the LLVM struct. Such a base may not have an entry
if the base does not have any fields/bases itself that would change the size of the struct. This utility method is useful for other frontends (Polygeist) that use Clang as an API to generate code.

Reviewed By: efriedma

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

While -g[no-]simple-template-names is a driver option, the fancier
-gsimple-template-names={simple,mangled} option is cc1-only, so code
to handle it in the driver is dead.

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

Adds flang/include/flang/Common/visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit().  Modifies most use sites in
the front-end and runtime to use common::visit().

The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.

Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().

Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.

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

There is a case when a function has pseudo probe intrinsics but the module it resides does not have the probe desc. This could happen when the current module is not built with `-fpseudo-probe-for-profiling` while a function in it calls some other function from a probed module. In thinLTO mode, the callee function could be imported and inlined into the current function.
While this is undefined behavior, I'm fixing the asm printer to not ICE and warn user about this.

Reviewed By: wenlei

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

This is the correct intended condition; the problematic case where
we don't want to try to build the plugin is "WIN32 AND LLVM_LINK_LLVM_DYLIB"
and thus the negation is "NOT WIN32 OR NOT LLVM_LINK_LLVM_DYLIB".

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

CLANG_TOOLS_DIR holds the the current bin/ directory, maybe with a %(build_mode)
placeholder. It is used to add the just-built binaries to $PATH for lit tests.
In most cases it equals LLVM_TOOLS_DIR, which is used for the same purpose.
But for a standalone build of clang, CLANG_TOOLS_DIR points at the build tree
and LLVM_TOOLS_DIR points at the provided LLVM binaries.

Currently CLANG_TOOLS_DIR is set in clang/test/, clang-tools-extra/test/, and
other things always built with clang. This is a few cryptic lines of CMake in
each place. Meanwhile LLVM_TOOLS_DIR is provided by configure_site_lit_cfg().

This patch moves CLANG_TOOLS_DIR to configure_site_lit_cfg() and renames it:
 - there's nothing clang-specific about the value
 - it will also replace LLD_TOOLS_DIR, LLDB_TOOLS_DIR etc (not in this patch)

It also defines CURRENT_LIBS_DIR. While I removed the last usage of
CLANG_LIBS_DIR in e4cab4e2, there are LLD_LIBS_DIR usages etc tha...

This is useful for the case that we don't need to implement
reifyReturnTypeShapes.

Reviewed By: jpienaar

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

This simplifies the implementation of eraseInstruction by moving the odd-replace-users-with-undef handling back to the only caller which uses it.  This handling was not obviously correct, so add the asserts which make it clear why this is safe to do at all.  The result is simpler code and stronger assertions.

This reverts commit 39b80c83.

This change was causing build failures on several build bots:
- https://lab.llvm.org/buildbot/#/builders/139/builds/19210
- https://lab.llvm.org/buildbot/#/builders/93/builds/7956

The documentation contained extra space.
Also remove https://github.com/llvm/llvm-project/issues/54296
from the list of issues by 3784e8cc as this commit did not
fix it (nor was it supposed to).

Assignment semantics was coughing up bad errors and crashes for
intrinsic assignments to unlimited polymorphic entities while
looking for any (impossible) user defined ASSIGNMENT(=) generic
or intrinsic type conversion.

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

Unlike other types, when lambdas are instanciated,
they are recreated from scratch.
When an unevaluated lambdas appear in the type of a function,
parameter it is instanciated in the wrong declaration context,
as parameters are transformed before the function.

To support lambda in function parameters, we try to
compute whether they are dependant without looking at the
declaration context.

This is a short term stopgap solution to avoid clang
iceing. A better fix might be to inject some kind of
transparent declaration with correctly computed dependency
for function parameters, variable templates, etc.

Fixes https://github.com/llvm/llvm-project/issues/50376
Fixes https://github.com/llvm/llvm-project/issues/51414
Fixes https://github.com/llvm/llvm-project/issues/51416
Fixes https://github.com/llvm/llvm-project/issues/51641
Fixes https://github.com/llvm/llvm-project/issues/54296

Reviewed By: aaron.ballman

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

Update the single check line that still had a hard-coded metadata
reference. This makes it more robust to slight changes in the metadata
numbering.

Fixes an incorrect transformation due to values overflowing
https://alive2.llvm.org/ce/z/uizoea

This patch removes --version as a clang -cc1 option.
  clang --version
and
  clang --cc1 -version
remain valid. This behaviour is consistent with clang -cc1as.

Previously, clang -cc1 accepted both --version and -version, but
only -version was acted upon. The call
  clang -cc1 --version
stalled without any message: --version was an accepted option but
triggered no action, and the driver waited for standard input.

Reviewed By: thakis

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

This reverts commit cff34ccb.

This relands commit d89f9e96

The original commit exposed several missing dependencies (e.g. latent bugs in SLP scheduling).  Most of these were fixed over the weekend and have had several days to bake.  The last was fixed this morning after being noticed in manual review of test changes yesterday.  See the review thread for links to each change.

Original commit message follows:

SLP currently schedules all instructions within a scheduling window which stretches from the first instruction potentially vectorized to the last. This window can include a very large number of unrelated instructions which are not being considered for vectorization. This change switches the code to only schedule the sub-graph consisting of the instructions being vectorized and their transitive users.

This has the effect of greatly reducing the amount of work performed in large basic blocks, and thus greatly improves compile time on degenerate examples. To understand the effects, I added some statistics (not planned for upstream contribution). Here's an illustration from my motivating example:

   Before this patch:

   704357 SLP                          - Number of calcDeps actions
   699021 SLP                          - Number of schedule calls
   5598 SLP                          - Number of ReSchedule actions
   59 SLP                          - Number of ReScheduleOnFail actions
   10084 SLP                          - Number of schedule resets
   8523 SLP                          - Number of vector instructions generated

   After this patch:

   102895 SLP                          - Number of calcDeps actions
   161916 SLP                          - Number of schedule calls
   5637 SLP                          - Number of ReSchedule actions
   55 SLP                          - Number of ReScheduleOnFail actions
   10083 SLP                          - Number of schedule resets
   8403 SLP                          - Number of vector instructions generated

I do want to highlight that there is a small difference in number of generated vector instructions. This example is hitting the bailout due to maximum window size, and the change in scheduling is slightly perturbing when and how we hit it. This can be seen in the RescheduleOnFail counter change. Given that, I think we can safely ignore.

The downside of this change can be seen in the large test diff. We group all vectorizable instructions together at the bottom of the scheduling region. This means that vector instructions can move quite far from their original point in code. While maybe undesirable, I don't see this as being a major problem as this pass is not intended to be a general scheduling pass.

For context, it's worth noting that the pre-scheduling that SLP does while building the vector tree is exactly the sub-graph scheduling implemented by this patch.

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

This patch adds MLIR NVVM support for the various NVPTX `mma.sync`
operations. There are a number of possible data type, shape,
and other attribute combinations supported by the operation, so a
custom assebmly format is added and attributes are inferred where
possible.

Reviewed By: ThomasRaoux

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

Follow up of https://reviews.llvm.org/D121488. Ensure lower bounds
are `1` when the related dimension extent is zero. Note that lower
bounds from descriptors are now guaranteed to fulfill this property
after the runtime/codegen patches.

Also fixes explicit shape array extent lowering when instantiating
variables to deal with negative extent cases (issue found while testing
LBOUND edge case). This notably caused allocation crashes when dealing
with automatic arrays with reversed bounds or negative size
specification expression. The standard specifies that the extent of such
arrays is zero. This change has some ripple effect in the current lit
tests.

Add move two helpers as part of this change:
- Add a helper to tell if a fir::ExtendedValue describes an assumed size
  array (last dimension extent is unknown to the compiler, both at compile
  time and runtime).

- Move and share getIntIfConstant from Character.cpp so that it can be
  used elsewhere (NFC).

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

After writing the commit message for 4b1bace28, realized that the mentioned optimization was rather straight forward.  We already have the code for scanning a block during region initialization, we can simply keep track if we've seen a stacksave or stackrestore.  If we haven't, none of these dependencies are relevant and we can avoid the relatively expensive scans entirely.

This is an extension of commit b7806c to handle one last case noticed in test changes for D118538.  Again, this is thought to be a latent bug in the existing code, though this time I have not managed to reduce tests for the original algoritthm.

The prior attempt had failed to account for this case:
  %a = alloca i8
  stacksave
  stackrestore
  store i8 0, i8* %a

If we allow '%a' to reorder into the stacksave/restore region, then the alloca will be deallocated before the use.  We will have taken a well defined program, and introduced a use-after-free bug.

There's also an inverse case where the alloca originally follows the stackrestore, and we need to prevent the reordering it above the restore.

Compile time wise, we potentially do an extra scan of the block for each alloca seen in a bundle.  This is significantly more expensive than the stacksave rooted version and is why I'd tried to avoid this in the initial patch.  There is room to optimize this (by essentially caching a "has stacksave" bit per block), but I'm leaving that to future work if it actually shows up in practice.  Since allocas in bundles should be rare in practice, I suspect we can defer the complexity for a long while.

CoverageMappingModuleGen generates a coverage mapping record
even for unused functions with internal linkage, e.g.
static int foo() { return 100; }
Clang frontend eliminates such functions, but InstrProfiling pass
still pulls in profile runtime since there is a coverage record.
Fuchsia uses runtime counter relocation, and pulling in profile
runtime for unused functions causes a linker error:
undefined hidden symbol: __llvm_profile_counter_bias.
Since 389dc94d, we do not hook profile runtime for the binaries
that none of its translation units have been instrumented in Fuchsia.
This patch extends that for the instrumented binaries that
consist of only unused functions.

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

This is to avoid false positives when using the uninstrumented assembly code implementation.

Update all places that currently assume the entry block to the plan is
also the vector loop header to use getVectorLoopRegion instead.

getVectorLoopRegion will keep doing the right thing when the pre-header
is modeled explicitly (and becomes the new entry block in the plan).

Fixes "Cannot specify link libraries for target "lldb-target-fuzzer"
which is not built by this project." Normally that's taken care of by
add_llvm_fuzzer but we need target_link_libraries for liblldb and our
utility library.

define canonicalizer and folder for tosa::select

Reviewed By: mehdi_amini, Mogball

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

The "seenProcs" sets passed as arguments to the procedure and dummy
procedure characterization routines need to be passed by value so that
local updates to those sets do not become permanent.  They are
presently passed by reference and that has led to bogus errors about
recursively defined procedures in testing.

(It might be faster to pass the sets by reference and undo those local
updates in these functions, but that's error-prone, and the performance
difference is not expected to be detectable in practice.)

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

This patch provides the user with the ability to disable all checked of accesses
to optionals that are the pointees of smart pointers. Since smart pointers are
not modeled (yet), the system cannot distinguish safe from unsafe accesses to
optionals through smart pointers. This results in false positives whenever
optionals are used through smart pointers. The patch gives the user the choice
of ignoring all positivess in these cases.

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

This patch solves two problems with the `HostDataToTargetMap` (HDTT
map) which caused races and crashes before:

1) Any access to the HDTT map needs to be exclusive access. This was not
   the case for the "dump table" traversals that could collide with
   updates by other threads. The new `Accessor` and `ProtectedObject`
   wrappers will ensure we have a hard time introducing similar races in
   the future. Note that we could allow multiple concurrent
   read-accesses but that feature can be added to the `Accessor` API
   later.
2) The elements of the HDTT map were `HostDataToTargetTy` objects which
   meant that they could be copied/moved/deleted as the map was changed.
   However, we sometimes kept pointers to these elements around after we
   gave up the map lock which caused potential races again. The new
   indirection through `HostDataToTargetMapKeyTy` will allows us to
   modify the map while keeping the (interesting part of the) entries
   val...

This patch adds a generic fuzzer that interprets inputs as object files
and uses them to create a target in lldb. It is very similar to the
llvm-dwarfdump fuzzer which found a bunch of issues in libObject.

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

Reduce the polynomial's degree from 7 down to 4.

Currently we use a degree-7 minimax polynomial on an interval of length 2^-7
around 0 to compute `expf`. Based on the suggestion of @santoshn and the RLIBM
project (https://github.com/rutgers-apl/rlibm-all/blob/main/source/float/exp.c)
and the improvement we made with `exp2f` in https://reviews.llvm.org/D122346,
it is possible to have a good polynomial of degree-4 on a subinterval of length
2^(-7) to approximate e^x.

We did try to either reduce the degree of the polynomial down to 3 or increase
the interval size to 2^(-6), but in both cases the number of exceptional values
exploded. So we settle with using a degree-4 polynomial of the interval of
size 2^(-7) around 0.

Reviewed By: sivachandra, zimmermann6, santoshn

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