Mach-O LLD uses the buffer identifier of the memory buffer backing an object
file to generate stabs which are used by `dsymutil` to find the object file for
dSYM generation.

When using thinLTO, these buffers are provided by the cache which initially
saves them to disk as temporary files beginning with "Thin-" but renames them
to persistent files beginning with "llvmcache-" before the buffer is provided
to the cache user.

However, the buffer is created before the file is renamed and is given the temp
file's name as an identifier. This causes the generated stabs to point to
nonexistent files.

This change names the buffer with the eventual persistent filename. I think
this is safe because failing to rename the temp file is a fatal error.

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

This patch fixes:

  lldb/source/Plugins/Platform/Windows/PlatformWindows.cpp:386:13:
  error: comparison between NULL and non-pointer ('lldb::addr_t' (aka
  'unsigned long') and NULL) [-Werror,-Wnull-arithmetic]

RECL= is required for direct access I/O, but is permitted
as well for sequential I/O, where it is defined by the
standard to specify a maximum record (line) length.
The standard does not say what should happen when an
sequential formatted input record appears whose length is
unequal to RECL= when it is specified.

Precedents from other compilers are unclear: one raises an error,
some honor RECL= as an effective truncation, and a few ignore the
situation.  On output, all other compilers tested raised an
error when an attempt is made to emit a record longer than RECL=.

This patch treats RECL= as effective truncation on input and
as a hard limit with error on output, and also ensures that
RECL= can be set *longer* than the actual input record lengths.

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

When targeting FreeBSD on a Linux host with a copy
of system libc++, Clang prepends /usr/include/c++/v1
to the search paths even with -ffreestanding, and
fails to compile a program with a
single #include <xmmintrin.h>

Dropping the path with -nostdlibinc.

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

getForArgument is missing support for atomic memory transfer
intrinsics. In terms of accessed locations they behave like regular
memory transfer intrinsics and we already support them as such in
getForSource/getForDest.

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

Instead of passing it as argument to the member function.

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

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

Do not compute SkipFirstExtraIndent just to see that there are no fake l
parens.

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

Let only the JS/TS users pay for the initialistation.

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

That's much easier to read.

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

Prefer to check the local variables first before dereferencing the
pointer.

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

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

In the loop there is also a Node.

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

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

Adding the following folding opportunity:
(~A | B) | (A ^ B) --> -1

https://alive2.llvm.org/ce/z/PMtdYB

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

The definition of the EXPONENT() intrinsic function differs by one
from the real arithmetic folding templates concept of an unbiased
exponent, and also needs special handling for zero.  Fix, and add
more tests.

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

This implements `DoLoadImage` and `UnloadImage` in the Windows platform
plugin modelled after the POSIX platform plugin.  This was previously
unimplemented and resulted in a difficult to decipher error without any
logging.

This implementation is intended to support enables the use of LLDB's
Swift REPL on Windows.

Paths which are added to the library search path are persistent and
applied to all subsequent loads.  This can be adjusted in the future by
storing all the cookies and restoring the path prior to returning from
the helper.  However, the dynamic path count makes this a bit more
challenging.

Reviewed By: @JDevlieghere
Differential Revision: https://reviews.llvm.org/D77287

Building xray with recent clang on a 64-bit system results in a number
of -Wformat warnings:

    compiler-rt/lib/xray/xray_allocator.h:70:11: warning: format specifies type 'int' but the argument has type '__sanitizer::uptr' (aka 'unsigned long') [-Wformat]
              RoundedSize, B);
              ^~~~~~~~~~~
    compiler-rt/lib/xray/xray_allocator.h:119:11: warning: format specifies type 'int' but the argument has type '__sanitizer::uptr' (aka 'unsigned long') [-Wformat]
              RoundedSize, B);
              ^~~~~~~~~~~

Since `__sanitizer::uptr` has the same size as `size_t`, these can be
fixed by using the printf specifier `%zu`.

    compiler-rt/lib/xray/xray_basic_logging.cpp:348:46: warning: format specifies type 'int' but the argument has type '__sanitizer::tid_t' (aka 'unsigned long long') [-Wformat]
          Report("Cleaned up log for TID: %d\n", GetTid());
                                          ~~     ^~~~~~~~
                                          %llu
    compiler-rt/lib/xray/xray_basic_logging.cpp:353:62: warning: format specifies type 'int' but the argument has type '__sanitizer::tid_t' (aka 'unsigned long long') [-Wformat]
          Report("Skipping buffer for TID: %d; Offset = %llu\n", GetTid(),
                                           ~~                    ^~~~~~~~
                                           %llu

Since `__sanitizer::tid_t` is effectively declared as `unsigned long
long`, these can be fixed by using the printf specifier `%llu`.

    compiler-rt/lib/xray/xray_basic_logging.cpp:354:14: warning: format specifies type 'unsigned long long' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat]
                 TLD.BufferOffset);
                 ^~~~~~~~~~~~~~~~

Since `BufferOffset` is declared as `size_t`, this one can be fixed by
using `%zu` as a printf specifier.

    compiler-rt/lib/xray/xray_interface.cpp:172:50: warning: format specifies type 'int' but the argument has type 'uint64_t' (aka 'unsigned long') [-Wformat]
        Report("Unsupported sled kind '%d' @%04x\n", Sled.Address, int(Sled.Kind));
                                       ~~            ^~~~~~~~~~~~
                                       %lu

Since ``xray::SledEntry::Address` is declared as `uint64_t`, this one
can be fixed by using `PRIu64`, and adding `<cinttypes>`.

    compiler-rt/lib/xray/xray_interface.cpp:308:62: warning: format specifies type 'long long' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat]
        Report("System page size is not a power of two: %lld\n", PageSize);
                                                        ~~~~     ^~~~~~~~
                                                        %zu
    compiler-rt/lib/xray/xray_interface.cpp:359:64: warning: format specifies type 'long long' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat]
        Report("Provided page size is not a power of two: %lld\n", PageSize);
                                                          ~~~~     ^~~~~~~~
                                                          %zu

Since `PageSize` is declared as `size_t`, these can be fixed by using
`%zu` as a printf specifier.

Reviewed By: vitalybuka

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

Avoid the use of deprecated (opaque pointer incompatible) APIs
in C API tests, in preparation for header deprecation. Add a
LLVMGetGEPSourceElementType() to cover a bit of functionality
that is necessary for the echo test.

This change is split out from https://reviews.llvm.org/D114936.

As suggested on D115098, this tests the positioning of
HotColdSplitting, IROutliner and MergeFunctions in the optimization
pipeline.

MergeFunctions (as well as HotColdSplitting an IROutliner) are
incorrectly scheduled under the new pass manager. The code makes
it look like they run towards the end of the module optimization
pipeline (as they should), while in reality the run at the start.
This is because the OptimizePM populated around them is only
scheduled later.

I'm fixing this by moving these three passes until after OptimizePM
to avoid splitting the function pass pipeline. It doesn't seem
important to me that some of the function passes run after these
late module passes.

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

729bf9b2 should have fixed these

This reverts commits
* ee691970 (D113741),
* 79d31329 (D114705)

due to lldb and dexter test failures.

Code using indirect calls is broken without this, and there isn't
really much value in supporting the old attempt to vary the argument
placement based on uses. This resulted in more argument shuffling code
anyway.

Also have the option stop implying all inputs need to be passed. This
will no rely on the amdgpu-no-* attributes to avoid passing
unnecessary values.

Previously we would require adding an attribute to kernels to enable
the inputs passed in the kernarg segment, accessed by
llvm.amdgcn.implicitarg.ptr. This violates the principle of being
correct by default. Some OpenMP testcases were broken recently since
it wasn't correctly setting this attribute, and no known frontends are
setting this to anything other than the maximum.

Most of the test changes are from load widening of argument loads
since there now more implied dereferenceable bytes.

We already annotate whether llvm.amdgcn.implicitarg.ptr is known to be
unused. Start using it to avoid allocating the implicit arguments if
unneeded.

This is another attempt to make function-local declarations
(like static variables, structs/classes and other) be correctly
emitted within a lexical (bracketed) block.

Fixes https://bugs.llvm.org/show_bug.cgi?id=19238.

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

When using -test-loop-permutation="permutation-map=...", applies the
permutation map on each affine nest in the function (and not only the
first one). If the size of the permutation map and the size of a nest
are not consistent, do nothing on this particular nest (instead of
making MLIR crash).

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

This patch proposes to move emission of global variables, types,
imported entities, etc from DwarfDebug::beginModule() to DwarfDebug::endModule().
Effectively, this changes nothing but the order of debug entities which
will be as follows:
* subprograms (including related context, local variables/labels,
  local imported entities; related types can be created as a part of
  the emission of local entities of an abstract subprogram);
* global variables (including related context and types);
* retained types and enums;
* non-local-scoped imported entities;
* basic types;
* other types left (as a part of local variables attributes emission).

Note that the order of emitted compile units may also be changed as now we emit
units that contain subprograms first and then all other non-empty units.

The motivation behind this change is the following:
(1) DwarfDebug::beginModule() is run at the very beginning of backend's pipeline,
    from this time IR can be significantly changed by target-specific passes.
    If it happens for debug metadata of global entities, those changes will not
    be reflected in the emitted DWARF.
(2) imported subprogram names should refer to an abstract subprogram if it exists,
    but it isn't known in DwarfDebug::beginModule() (it's possible to make some
    guesses based on location info, but it's not quite reliable);
(3) aforementioned entities if they are scoped within a bracketed block
    (subject of D113741) couldn't be emitted in DwarfDebug::beginModule()
    (they need parent emitted first). Another problem is if to try to gather
    some information about local entities and defer their emission
    (till subprogram's processing or DwarfDebug::endModule()) all the gathered
    details might be irrelevant / invalid by the time the entities are being
    emitted (because of (1)).

Reviewed By: dblaikie

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

Fails on bots: https://lab.llvm.org/buildbot#builders/184/builds/1580

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

Swap AIC and IC neighbouring in pipeline. This looks more natural and even
almost has no effect for now (three slightly touched tests of test-suite). Also
this could be the first step towards merging AIC (or its part) to -O2 pipeline.

After several changes in AIC (like D108091, D108201, D107766, D109515, D109236)
there've been observed several regressions (like PR52078, PR52253, PR52289)
that were fixed in different passes (see D111330, D112721) by extending their
functionality, but these regressions were exposed since changed AIC prevents IC
from making some of early optimizations.

This is common problem and it should be fixed by just moving AIC after IC
which looks more logically by itself: make aggressive instruction combining
only after failed ordinary one.

Fixes PR52289

Reviewed By: spatel, RKSimon

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

The ray_origin, ray_dir and ray_inv_dir arguments should all be vec3 to
match how the hardware instruction works.

Don't change the API of the corresponding OpenCL builtins.

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

Add generic support for vec3 types, and in particular define
llvm_v3f32_ty which will be used by AMDGPU's
llvm.amdgcn.image.bvh.intersect.ray intrinsic.

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

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

Add an -enable-merge-functions option to allow testing of function
merging as it will actually happen in the optimization pipeline.
Based on that add a test where we currently produce two identical
functions without merging them due to incorrect pass scheduling
under the new pass manager.

Currently it's hidden inside ClangTidyDiagnosticConsumer,
so it's hard to know it exists.

Given that there are multiple uses of globs in clang-tidy,
it makes sense to have these classes publicly available
for other use cases that might benefit from it.

Also, add unit test by converting the existing tests
for GlobList into typed tests.

Reviewed By: salman-javed-nz

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