Reviewed By: jsji

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

whitespace only, no behavior change

Previously, lld/mac only ad-hoc codesigned executables on arm64.

Matches ld64 behavior. Part of PR49443. Fixes 14 of 17 failures when running
check-llvm with lld as host linker on an M1 MBP.

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

Some BPF programs compiled on s390 fail to load, because s390
arch-specific linux headers contain float and double types. At the
moment there is no BTF_KIND for floats and doubles, so the release
version of LLVM ends up emitting type id 0 for them, which the
in-kernel verifier does not accept.

Introduce support for such types to libbpf by representing them using
the new BTF_KIND_FLOAT.

Reviewed By: yonghong-song

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

We have no way to reason about the bool returned by try_emplace, so we
simply ignore any std::move()s that happen in a try_emplace argument.
A lot of the time in this situation, the code will be checking the
bool and doing something else if it turns out the value wasn't moved
into the map, and this has been causing false positives so far.

I don't currently have any intentions of handling "maybe move" functions
more generally.

Reviewed By: sammccall

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

A bug was introduced when adding -munsafe-fp-atomics.
By default it should be off.

Reviewed by: Artem Belevich

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

Like nvptx and some other targets, -mconstructor-aliases does not work well with amdgpu,
therefore we disable it in the same approach.

Reviewed by: Artem Belevich

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

`mix` is subtly different from `clamp`: in the overloads where the
last argument is a scalar, the second argument should be a gentype for
`mix`.

As scalars can be implicitly converted to vectors, this cannot be
caught in the Sema test.  Hence adding a CodeGen test, where we can
verify the types using the mangled name.

Previously if we couldn't run the clang-format command
for some reason, you'd get an unhelpful error message:
```
OSError: [Errno 2] No such file or directory
```

Which doesn't tell you what was happening to cause this.

Catch the error and add the command we were attempting to run:
```
RuntimeError: Failed to run "<...>/clang-food <...>" - No such file or directory"
RuntimeError: Failed to run "<...>/clang-format <...>" - Permission denied"
```

Reviewed By: krasimir

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

Rewrites test to use correct architecture triple; fixes incorrect
reference in SourceLevelDebugging doc; simplifies `spillReg` behaviour
so as to not be dependent on changes elsewhere in the patch stack.

This reverts commit d2000b45.

This patch uses the errno python library to print out the correct error messages instead of hardcoding the error message per platform.

Reviewed By: jhenderson, ASDenysPetrov

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

Same as other memory instructions, ds instructions add latency even if
exec is zero. Jumping over them if exec=0 is cheaper than executing
them.
With this change, the branch instruction that skips over a basic block
if exec=0 is not removed when the block contains a ds instruction.

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

Revert rG8198d839: "[X86] Pass to transform amx intrinsics to scalar operation."

This reverts commit 8198d839.due to buildbot breakages

This patch fixes LLD to allow element sections for tables whose number
is nonzero.  We also add a test for linking multiple tables, showing
that nonzero table numbers for the indirect function table,
user-declared imported tables, and local user table definitions work.

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

The new test llvm/test/Transforms/CodeGenPrepare/remove-assume-block.ll
breaks on non-X86 machines. Change it to look like the existing test
llvm/test/Transforms/CodeGenPrepare/X86/delete-assume-dead-code.ll
to fix it.

Reviewed By: bkramer

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

With reference types, tables can have non-zero table numbers.  This
commit adds support for element sections against these tables.

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

Clang exposes an interface for extending the PCM/PCH file format: `ModuleFileExtension`.

Clang itself has only a single implementation of the interface: `TestModuleFileExtension` that can be instantiated via the `-ftest-module-file_extension=` command line argument (and is stored in `FrontendOptions::ModuleFileExtensions`).

Clients of the Clang library can extend the PCM/PCH file format by pushing an instance of their extension class to the `FrontendOptions::ModuleFileExtensions` vector.

When generating the `-ftest-module-file_extension=` command line argument from `FrontendOptions`, a downcast is used to distinguish between the Clang's testing extension and other (client) extensions.

This functionality is enabled by LLVM-style RTTI. However, this style of RTTI is hard to extend, as it requires patching Clang (adding new case to the `ModuleFileExtensionKind` enum).

This patch switches to the LLVM RTTI for open class hierarchies, which allows libClang users (e.g. Swift) to create implementations of `ModuleFileExtension` without patching Clang. (Documentation of the feature: https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html#rtti-for-open-class-hierarchies)

Reviewed By: artemcm

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

Recommit bf5a5826. Depends on
4c8fb7dd which was reverted.

RegBankSelect creates zext and trunc when it selects banks for uniform i1.
Add zext_trunc_fold from generic combiner to post RegBankSelect combiner.

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

Recommit 4112299e. Depends on
4c8fb7dd which was reverted.

Combine zext(trunc x) to x when truncated bits are known to be zero.

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

There are certain loops like this below:

  for (int i = 0; i < n; i++) {
    a[i] = b[i] + 1;
    *inv = a[i];
  }

that can only be vectorised if we are able to extract the last lane of the
vectorised form of 'a[i]'. For fixed width vectors this already works since
we know at compile time what the final lane is, however for scalable vectors
this is a different story. This patch adds support for extracting the last
lane from a scalable vector using a runtime determined lane value. I have
added support to VPIteration for runtime-determined lanes that still permit
the caching of values. I did this by introducing a new class called VPLane,
which describes the lane we're dealing with and provides interfaces to get
both the compile-time known lane and the runtime determined value. Whilst
doing this work I couldn't find any explicit tests for extracting the last
lane values of fixed width vectors so I added tests for both scalable and
fixed width vectors.

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

This patch fixes failure of the `CodeGen/aix-ignore-xcoff-visibility.cpp` test with command line round-trip.

The absence of '-fvisibility' implies '-mignore-xcoff-visibility'.

The problem is that when '-fvisibility default' is passed to -cc1, it isn't being generated. (This adheres to the principle that generation doesn't produce arguments with default values.)

However, that caused '-mignore-xcoff-visibility' to be implied in the generated command line (without '-fvisibility'), while it wasn't implied in the original command line (with '-fvisibility').

This patch fixes that by always generating '-fvisibility' and explains the situation in comment.

(The '-mginore-xcoff-visibility' option was added in D87451).

Reviewed By: Bigcheese

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

Canonicalize the iter_args of an scf::ForOp that involve a tensor_load and
for which only the last loop iteration is actually visible outside of the
loop. The canonicalization looks for a pattern such as:
```
   %t0 = ... : tensor_type
   %0 = scf.for ... iter_args(%bb0 : %t0) -> (tensor_type) {
     ...
     // %m is either tensor_to_memref(%bb00) or defined above the loop
     %m... : memref_type
     ... // uses of %m with potential inplace updates
     %new_tensor = tensor_load %m : memref_type
     ...
     scf.yield %new_tensor : tensor_type
   }
```

`%bb0` may have either 0 or 1 use. If it has 1 use it must be exactly a
`%m = tensor_to_memref %bb0` op that feeds into the yielded `tensor_load`
op.

If no aliasing write of `%new_tensor` occurs between tensor_load and yield
then the value %0 visible outside of the loop is the last `tensor_load`
produced in the loop.

For now, we approximate the absence of aliasing by only supporting the case
when the tensor_load is the operation immediately preceding the yield.

The canonicalization rewrites the pattern as:
```
   // %m is either a tensor_to_memref or defined above
   %m... : memref_type
   scf.for ... { // no iter_args
     ... // uses of %m with potential inplace updates
   }
   %0 = tensor_load %m : memref_type
```

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

* https://wg21.link/P1682

Reviewed By: ldionne, Mordante, #libc

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

As pointed out in D96244, "Module" is already pretty overloaded to refer
to clang and llvm modules. (And clangd deals directly with the former).

FeatureModule is a bit of a mouthful but it's pretty self-descriptive.
I think it might be better than "Component" which doesn't really capture
the "common interface" aspect - it's IMO confusing to refer to
"components" but exclude CDB for example.

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

The code was using the standard isalnum function which doesn't handle
values outside the non-ascii range. Switching to using llvm::isAlnum
instead ensures we don't provoke undefined behaviour, which can in some
cases result in crashes.

Reviewed by: MaskRay

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

The test was showing that when --strip-unneeded is specified for an
executable, all the symbols are stripped. However, the set of symbols
used in the test would be stripped by --strip-unneeded for an ET_REL
object too. Fix this by adding additional symbols that aren't normally
stripped by --strip-unneeded.

Reviewed by: MaskRay

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

To work around https://sourceware.org/bugzilla/show_bug.cgi?id=27490

Opening a path like \\server (without a trailing share name and
path) produces this error, while opening e.g. \\server\share
(for a nonexistent server/share) produces ERROR_BAD_NETPATH (which
already is mapped).

This happens in some testcases (in fs.op.proximate); as proximate()
calls weakly_canonical() on the inputs, weakly_canonical() checks
whether the path exists or not. When the error code wasn't recognized
(it mapped to errc::invalid_argument), the stat operation wasn't
conclusive and weakly_canonical() errored out. With the proper error
code mapping, this isn't considered an error, just a nonexistent
path, and weakly_canonical() can proceed.

This roughly matches what MS STL does - it doesn't have
ERROR_BAD_PATHNAME in its error code mapping table, but it
checks for this error code specifically in the return of their
correspondence of the stat function.

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

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

Also add WIN32_LEAN_AND_MEAN before including windows.h, for consistency
with other sources.

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

One ASan test currently `XPASS`es on Solaris:

  AddressSanitizer-i386-sunos :: TestCases/Posix/unpoison-alternate-stack.cpp

It was originally `XFAIL`ed in D88501 <https://reviews.llvm.org/D88501>
because `longjmp` from a signal handled is highly unportable, warned
against in XPG7, and was not supported by Solaris `libc` at the time.

However, since then support has been added for some cases including the
current one, so the `XFAIL` can go.

Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.

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

One ASan test currently `XPASS`es on Solaris:

  AddressSanitizer-i386-sunos :: TestCases/Posix/no_asan_gen_globals.c

It was originally `XFAIL`ed in D88218 <https://reviews.llvm.org/D88218>
because Solaris `ld`, unlike GNU `ld`, doesn't strip local labels.  Since
then, the integrated assembler has stopped emitting those local labels, so
the difference becomes moot and the `XFAIL` can go.

Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.

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

This pass runs in any situations but we skip it when it is not O0 and the
function doesn't have optnone attribute. With -O0, the def of shape to amx
intrinsics is near the amx intrinsics code. We are not able to find a
point which post-dominate all the shape and dominate all amx intrinsics.
To decouple the dependency of the shape, we transform amx intrinsics
to scalar operation, so that compiling doesn't fail. In long term, we
 should improve fast register allocation to allocate amx register.

Reviewed By: pengfei

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

GCC warning:
```
In file included from /usr/include/c++/9/cassert:44,
from /home/vsts/work/1/llvm-project/llvm/include/llvm/ADT/BitVector.h:21,
from /home/vsts/work/1/llvm-project/llvm/include/llvm/Support/Program.h:17,
from /home/vsts/work/1/llvm-project/llvm/include/llvm/Support/Process.h:32,
from /home/vsts/work/1/llvm-project/llvm/lib/ExecutionEngine/JITLink/JITLinkMemoryManager.cpp:11:
/home/vsts/work/1/llvm-project/llvm/lib/ExecutionEngine/JITLink/JITLinkMemoryManager.cpp: In member function ‘virtual llvm::Expected<std::unique_ptr<llvm::jitlink::JITLinkMemoryManager::Allocation> > llvm::jitlink::InProcessMemoryManager::allocate(const llvm::jitlink::JITLinkDylib*, const SegmentsRequestMap&)’:
/home/vsts/work/1/llvm-project/llvm/lib/ExecutionEngine/JITLink/JITLinkMemoryManager.cpp:129:40: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
129 |   assert(SlabRemaining.allocatedSize() >= 0 && "Mapping exceeds allocation");
    |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
```

The return type of `allocatedSize()` is `size_t`, thus the expression
`SlabRemaining.allocatedSize() >= 0` always evaluate to `true`.

[SelectionDAG] Assert that operands to SelectionDAG::getNode are not DELETED_NODE to catch issues like PR49393 earlier.

I'm not sure this would catch all such issues, but it would catch some.

The problem for PR49393 was that we were holding a reference to a node that
wasn't connect edto the DAG across a function that could delete unused nodes. In
this particular case we managed to try to use the deleted node while it was in
the deleted state before its memory got recycled.

It could also happen that we delete the node, something allocates a new node
which recycles the memory. Then  we try to use the reference we were holding and
it is now a completely different node with different valid opcode. This patch
would not catch that.

Reviewed By: spatel

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

[TargetLowering] Use HandleSDNodes to prevent nodes from being deleted by recursive calls in getNegatedExpression.

For binary or ternary ops we call getNegatedExpression multiple
times and then compare costs. While we're doing this we need to
hold a node from the first call across the second call, but its
not yet attached to the DAG. Its possible the second call creates
an identical node and then decides it didn't need it so will try
to delete it if it has no uses. This can cause a reference to the
node we're holding further up the call stack to become invalidated.

To prevent this, we can use a HandleSDNode to artifically give
the node a use without connecting it to the DAG.

I've used a std::list of HandleSDNodes so we can create handles
only when we have a node to hold. HandleSDNode does not have
default constructor and cannot be copied or moved.

Fixes PR49393.

Reviewed By: spatel

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