platform/upstream/llvm.git
3 years ago[libcxx] Implement semaphores for windows
Martin Storsjö [Thu, 25 Feb 2021 22:41:35 +0000 (00:41 +0200)]
[libcxx] Implement semaphores for windows

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

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

3 years ago[asan][test] Don't XFAIL Posix/unpoison-alternate-stack.cpp on Solaris
Rainer Orth [Fri, 5 Mar 2021 08:43:47 +0000 (09:43 +0100)]
[asan][test] Don't XFAIL Posix/unpoison-alternate-stack.cpp on Solaris

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

3 years ago[asan][test] Don't XFAIL Posix/no_asan_gen_globals.c on Solaris
Rainer Orth [Fri, 5 Mar 2021 08:42:29 +0000 (09:42 +0100)]
[asan][test] Don't XFAIL Posix/no_asan_gen_globals.c on Solaris

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

3 years ago[X86] Pass to transform amx intrinsics to scalar operation.
Luo, Yuanke [Thu, 4 Mar 2021 01:42:06 +0000 (09:42 +0800)]
[X86] Pass to transform amx intrinsics to scalar operation.

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

3 years ago[JITLink] Fix Wtype-limits gcc warning (NFC)
Yang Fan [Fri, 5 Mar 2021 07:27:10 +0000 (15:27 +0800)]
[JITLink] Fix Wtype-limits gcc warning (NFC)

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`.

3 years ago[SelectionDAG] Assert that operands to SelectionDAG::getNode are not DELETED_NODE...
Craig Topper [Fri, 5 Mar 2021 07:05:30 +0000 (23:05 -0800)]
[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

3 years ago[TargetLowering] Use HandleSDNodes to prevent nodes from being deleted by recursive...
Craig Topper [Fri, 5 Mar 2021 06:30:38 +0000 (22:30 -0800)]
[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

3 years ago[Driver][test] Fix ClangDriverTest
Fangrui Song [Fri, 5 Mar 2021 06:44:37 +0000 (22:44 -0800)]
[Driver][test] Fix ClangDriverTest

3 years ago[Driver] Switch Exherbo/Alpine/Arch Linux to /etc/os-release
Fangrui Song [Fri, 5 Mar 2021 06:31:05 +0000 (22:31 -0800)]
[Driver] Switch Exherbo/Alpine/Arch Linux to /etc/os-release

3 years ago[libcxx] fixes up some [concepts]-related code
Christopher Di Bella [Fri, 5 Mar 2021 06:07:45 +0000 (22:07 -0800)]
[libcxx] fixes up some [concepts]-related code

* moves `std::copy_constructible` so it comes before
  `std::equality_comparable_with`
* replaces a few uses of `auto`

3 years ago[DebugInfo] Delete unused DIVariable::getSource
Fangrui Song [Fri, 5 Mar 2021 05:53:13 +0000 (21:53 -0800)]
[DebugInfo] Delete unused DIVariable::getSource

3 years ago[DebugInfo] Delete deleted getLine/getColumn
Fangrui Song [Fri, 5 Mar 2021 05:49:21 +0000 (21:49 -0800)]
[DebugInfo] Delete deleted getLine/getColumn

r250405 deleted the functions from DILexicalBlockBase.

3 years ago[lldb] Rename QueueFundamentalPlan to QueueBasePlan (NFC)
Dave Lee [Tue, 2 Mar 2021 21:18:35 +0000 (13:18 -0800)]
[lldb] Rename QueueFundamentalPlan to QueueBasePlan (NFC)

Minor change for naming consistency.

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

3 years ago[clang][StaticAnalyzer] Compilation fix.
Michael Kruse [Fri, 5 Mar 2021 05:21:29 +0000 (23:21 -0600)]
[clang][StaticAnalyzer] Compilation fix.

An enum was unhandled after landing of D94973. Add the new
OMPCanonicalLoopClass to the list of unhandled cases.

3 years ago[sanitizer,NFC] Fix long comment formating
Vitaly Buka [Fri, 5 Mar 2021 04:57:11 +0000 (20:57 -0800)]
[sanitizer,NFC] Fix long comment formating

3 years ago[clang][OpenMP] Use OpenMPIRBuilder for workshare loops.
Michael Kruse [Wed, 3 Mar 2021 23:15:32 +0000 (17:15 -0600)]
[clang][OpenMP] Use OpenMPIRBuilder for workshare loops.

Initial support for using the OpenMPIRBuilder by clang to generate loops using the OpenMPIRBuilder. This initial support is intentionally limited to:
 * Only the worksharing-loop directive.
 * Recognizes only the nowait clause.
 * No loop nests with more than one loop.
 * Untested with templates, exceptions.
 * Semantic checking left to the existing infrastructure.

This patch introduces a new AST node, OMPCanonicalLoop, which becomes parent of any loop that has to adheres to the restrictions as specified by the OpenMP standard. These restrictions allow OMPCanonicalLoop to provide the following additional information that depends on base language semantics:
 * The distance function: How many loop iterations there will be before entering the loop nest.
 * The loop variable function: Conversion from a logical iteration number to the loop variable.

These allow the OpenMPIRBuilder to act solely using logical iteration numbers without needing to be concerned with iterator semantics between calling the distance function and determining what the value of the loop variable ought to be. Any OpenMP logical should be done by the OpenMPIRBuilder such that it can be reused MLIR OpenMP dialect and thus by flang.

The distance and loop variable function are implemented using lambdas (or more exactly: CapturedStmt because lambda implementation is more interviewed with the parser). It is up to the OpenMPIRBuilder how they are called which depends on what is done with the loop. By default, these are emitted as outlined functions but we might think about emitting them inline as the OpenMPRuntime does.

For compatibility with the current OpenMP implementation, even though not necessary for the OpenMPIRBuilder, OMPCanonicalLoop can still be nested within OMPLoopDirectives' CapturedStmt. Although OMPCanonicalLoop's are not currently generated when the OpenMPIRBuilder is not enabled, these can just be skipped when not using the OpenMPIRBuilder in case we don't want to make the AST dependent on the EnableOMPBuilder setting.

Loop nests with more than one loop require support by the OpenMPIRBuilder (D93268). A simple implementation of non-rectangular loop nests would add another lambda function that returns whether a loop iteration of the rectangular overapproximation is also within its non-rectangular subset.

Reviewed By: jdenny

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

3 years ago[dfsan,NFC] Suppress cpplint warning
Vitaly Buka [Fri, 5 Mar 2021 04:42:18 +0000 (20:42 -0800)]
[dfsan,NFC] Suppress cpplint warning

3 years ago[LangRef] lifetime intrinsics: don't use word 'offset'
Juneyoung Lee [Fri, 5 Mar 2021 03:52:32 +0000 (12:52 +0900)]
[LangRef] lifetime intrinsics: don't use word 'offset'

from Philip's comments

3 years ago[clang][AST] Fix Wreturn-type gcc warning (NFC)
Yang Fan [Fri, 5 Mar 2021 03:24:55 +0000 (11:24 +0800)]
[clang][AST] Fix Wreturn-type gcc warning (NFC)

GCC warning:
```
/llvm-project/clang-tools-extra/clangd/SemanticHighlighting.cpp: In function ‘bool clang::clangd::{anonymous}::canHighlightName(clang::DeclarationName)’:
/llvm-project/clang-tools-extra/clangd/SemanticHighlighting.cpp:64:1: warning: control reaches end of non-void function [-Wreturn-type]
   64 | }
      | ^
```

3 years ago[RISCV] Enable fixed-length vectorization of LoopVectorizer for RISC-V Vector
Luke [Fri, 26 Feb 2021 14:10:30 +0000 (22:10 +0800)]
[RISCV] Enable fixed-length vectorization of LoopVectorizer for RISC-V Vector

By implementing the method "unsigned RISCVTTIImpl::getRegisterBitWidth(bool Vector)",
fixed-length vectorization is enabled when possible. Without this method, the
"#pragma clang loop" directive is needed to enable vectorization(or the cost model
may inform LLVM that "Vectorization is possible but not beneficial").

Reviewed By: frasercrmck

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

3 years ago[SampleFDO] Another fix to prevent repeated indirect call promotion in
Wei Mi [Sat, 20 Feb 2021 06:43:21 +0000 (22:43 -0800)]
[SampleFDO] Another fix to prevent repeated indirect call promotion in
sample loader pass.

In https://reviews.llvm.org/rG5fb65c02ca5e91e7e1a00e0efdb8edc899f3e4b9,
to prevent repeated indirect call promotion for the same indirect call
and the same target, we used zero-count value profile to indicate an
indirect call has been promoted for a certain target. We removed
PromotedInsns cache in the same patch. However, there was a problem in
that patch described below, and that problem led me to add PromotedInsns
back as a mitigation in
https://reviews.llvm.org/rG4ffad1fb489f691825d6c7d78e1626de142f26cf.

When we get value profile from metadata by calling getValueProfDataFromInst,
we need to specify the maximum possible number of values we expect to read.
We uses MaxNumPromotions in the last patch so the maximum number of value
information extracted from metadata is MaxNumPromotions. If we have many
values including zero-count values when we write the metadata, some of them
will be dropped when we read them because we only read MaxNumPromotions
values. It will allow repeated indirect call promotion again. We need to
make sure if there are values indicating promoted targets, those values need
to be saved in metadata with higher priority than other values.

The patch fixed that problem. We change to use -1 to represent the count
of a promoted target instead of 0 so it is easier to sort the values.
When we prepare to update the metadata in updateIDTMetaData, we will sort
the values in the descending count order and extract only MaxNumPromotions
values to write into metadata. Since -1 is the max uint64_t number, if we
have equal to or less than MaxNumPromotions of -1 count values, they will
all be kept in metadata. If we have more than MaxNumPromotions of -1 count
values, we will only save MaxNumPromotions such values maximally. In such
case, we have logic in place in doesHistoryAllowICP to guarantee no more
promotion in sample loader pass will happen for the indirect call, because
it has been promoted enough.

With this change, now we can remove PromotedInsns without problem.

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

3 years ago[libcxx] adds concepts std::equality_comparable[_with]
Christopher Di Bella [Fri, 5 Mar 2021 01:18:23 +0000 (17:18 -0800)]
[libcxx] adds concepts std::equality_comparable[_with]

Implements parts of:
    - P0898R3 Standard Library Concepts
    - P1754 Rename concepts to standard_case for C++20, while we still can

Depends on D96660

Reviewed By: ldionne, #libc, Quuxplusone

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

3 years ago[XCOFF][DebugInfo] support DWARF for XCOFF for assembly output.
Chen Zheng [Fri, 5 Mar 2021 01:47:41 +0000 (20:47 -0500)]
[XCOFF][DebugInfo] support DWARF for XCOFF for assembly output.

Reviewed By: jasonliu

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

3 years ago[dfsan] Remove hardcoded shadow width in array.ll
George Balatsouras [Thu, 4 Mar 2021 23:42:25 +0000 (15:42 -0800)]
[dfsan] Remove hardcoded shadow width in array.ll

As a preparation step for fast8 support, we need to update the tests
to pass in both modes. That requires generalizing the shadow width
and remove any hard coded references that assume it's always 2 bytes.

Reviewed By: stephan.yichao.zhao

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

3 years agoBPF: permit type modifiers for __builtin_btf_type_id() relocation
Yonghong Song [Thu, 4 Mar 2021 20:58:22 +0000 (12:58 -0800)]
BPF: permit type modifiers for __builtin_btf_type_id() relocation

Lorenz Bauer from Cloudflare tried to use "const struct <name>"
as the type for __builtin_btf_type_id(*(const struct <name>)0, 1)
relocation and hit a llvm BPF fatal error.
   https://lore.kernel.org/bpf/a3782f71-3f6b-1e75-17a9-1827822c2030@fb.com/

   ...
   fatal error: error in backend: Empty type name for BTF_TYPE_ID_REMOTE reloc

Currently, we require the debuginfo type itself must have a name.
In this case, the debuginfo type is "const" which points to "struct <name>".
The "const" type does not have a name, hence the above fatal error
will be triggered.

Let us permit "const" and "volatile" type modifiers. We skip modifiers
in some other cases as well like structure member type tracing.
This can aviod the above fatal error.

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

3 years agoFix clang for header move in LLVM/IR
David Blaikie [Fri, 5 Mar 2021 00:20:44 +0000 (16:20 -0800)]
Fix clang for header move in LLVM/IR

3 years agoMove llvm/Analysis/ObjCARCUtil.h to IR to fix layering.
David Blaikie [Fri, 5 Mar 2021 00:14:53 +0000 (16:14 -0800)]
Move llvm/Analysis/ObjCARCUtil.h to IR to fix layering.

This is included from IR files, and IR doesn't/can't depend on Analysis
(because Analysis depends on IR).

Also fix the implementation - don't use non-member static in headers, as
it leads to ODR violations, inaccurate "unused function" warnings, etc.
And fix the header protection macro name (we don't generally include
"LIB" in the names, so far as I can tell).

3 years ago[gn build] port b973e2e2f27e
Nico Weber [Thu, 4 Mar 2021 23:40:52 +0000 (18:40 -0500)]
[gn build] port b973e2e2f27e

3 years ago[dfsan] Propagate origin tracking at store
Jianzhou Zhao [Tue, 2 Mar 2021 18:59:07 +0000 (18:59 +0000)]
[dfsan] Propagate origin tracking at store

This is a part of https://reviews.llvm.org/D95835.

Reviewed By: morehouse, gbalats

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

3 years ago[docs] Remove some stale wording from gc.relocate description
Philip Reames [Thu, 4 Mar 2021 23:18:11 +0000 (15:18 -0800)]
[docs] Remove some stale wording from gc.relocate description

We dropped support for the non-bundle form a while back, but I apparently missed updating one place in the docs.

3 years ago[docs] Move statepoint related intrinsics into main LangRef
Philip Reames [Thu, 4 Mar 2021 23:12:36 +0000 (15:12 -0800)]
[docs] Move statepoint related intrinsics into main LangRef

3 years ago[AArch64][GlobalISel][RegBankSelect] Improve rbs of G_BUILD_VECTOR when fed by fp...
Amara Emerson [Thu, 4 Mar 2021 18:18:31 +0000 (10:18 -0800)]
[AArch64][GlobalISel][RegBankSelect] Improve rbs of G_BUILD_VECTOR when fed by fp values.

This is actually two changes. One is to avoid copies when fp values are fed into
a build_vector, without being able to tell from the opcode.

The other is that build_vectors are also marked as only defining FP, since they
produce vector results.

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

3 years ago[WebAssembly] Fix ExceptionInfo grouping again
Heejin Ahn [Thu, 4 Mar 2021 10:14:23 +0000 (02:14 -0800)]
[WebAssembly] Fix ExceptionInfo grouping again

This is a case D97677 missed. When taking out remaining BBs that are
reachable from already-taken-out exceptions (because they are not
subexcptions but unwind destinations), I assumed the remaining BBs are
not EH pads, but they can be. For example,
```
try {
  try {
    throw 0;
  } catch (int) { // (a)
  }
} catch (int) {   // (b)
}
try {
  foo();
} catch (int) {   // (c)
}
```
In this code, (b) is the unwind destination of (a) so its exception is
taken out of (a)'s exception, But even though the next try-catch is not
inside the first two-level try-catches, because the first try always
throws, its continuation BB is unreachable and the whole rest of the
function is dominated by EH pad (a), including EH pad (c). So after we
take out of (b)'s exception out of (a)'s, we also need to take out (c)'s
exception out of (a)'s, because (c) is reachable from (b).

This adds one more step before what we did for remaining BBs in D97677;
it traverses EH pads first to take subexceptions out of their incorrect
parent exception. It's the same thing as D97677, but because we can do
this before we add BBs to exceptions' sets, we don't need to fix sets
and only need to fix parent exception pointers.

Other changes are variable name changes (I changed `WE` -> `SrcWE`,
`UnwindWE` -> `DstWE` for clarity), some comment changes, and a drive-by
fix in a bug in a `LLVM_DEBUG` print statement.

Fixes https://github.com/emscripten-core/emscripten/issues/13588.

Reviewed By: dschuff

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

3 years ago[gn build] Port 561abd83ffec
LLVM GN Syncbot [Thu, 4 Mar 2021 22:58:35 +0000 (22:58 +0000)]
[gn build] Port 561abd83ffec

3 years ago[WebAssembly] Disable uses of __clang_call_terminate
Heejin Ahn [Tue, 2 Mar 2021 23:05:30 +0000 (15:05 -0800)]
[WebAssembly] Disable uses of __clang_call_terminate

Background:

Wasm EH, while using Windows EH (catchpad/cleanuppad based) IR, uses
Itanium-based libraries and ABIs with some modifications.

`__clang_call_terminate` is a wrapper generated in Clang's Itanium C++
ABI implementation. It contains this code, in C-style pseudocode:
```
void __clang_call_terminate(void *exn) {
  __cxa_begin_catch(exn);
  std::terminate();
}
```
So this function is a wrapper to call `__cxa_begin_catch` on the
exception pointer before termination.

In Itanium ABI, this function is called when another exception is thrown
while processing an exception. The pointer for this second, violating
exception is passed as the argument of this `__clang_call_terminate`,
which calls `__cxa_begin_catch` with that pointer and calls
`std::terminate` to terminate the program.

The spec (https://libcxxabi.llvm.org/spec.html) for `__cxa_begin_catch`
says,
```
When the personality routine encounters a termination condition, it
will call __cxa_begin_catch() to mark the exception as handled and then
call terminate(), which shall not return to its caller.
```

In wasm EH's Clang implementation, this function is called from
cleanuppads that terminates the program, which we also call terminate
pads. Cleanuppads normally don't access the thrown exception and the
wasm backend converts them to `catch_all` blocks. But because we need
the exception pointer in this cleanuppad, we generate
`wasm.get.exception` intrinsic (which will eventually be lowered to
`catch` instruction) as we do in the catchpads. But because terminate
pads are cleanup pads and should run even when a foreign exception is
thrown, so what we have been doing is:
1. In `WebAssemblyLateEHPrepare::ensureSingleBBTermPads()`, we make sure
terminate pads are in this simple shape:
```
%exn = catch
call @__clang_call_terminate(%exn)
unreachable
```
2. In `WebAssemblyHandleEHTerminatePads` pass at the end of the
pipeline, we attach a `catch_all` to terminate pads, so they will be in
this form:
```
%exn = catch
call @__clang_call_terminate(%exn)
unreachable
catch_all
call @std::terminate()
unreachable
```
In `catch_all` part, we don't have the exception pointer, so we call
`std::terminate()` directly. The reason we ran HandleEHTerminatePads at
the end of the pipeline, separate from LateEHPrepare, was it was
convenient to assume there was only a single `catch` part per `try`
during CFGSort and CFGStackify.

---

Problem:

While it thinks terminate pads could have been possibly split or calls
to `__clang_call_terminate` could have been duplicated,
`WebAssemblyLateEHPrepare::ensureSingleBBTermPads()` assumes terminate
pads contain no more than calls to `__clang_call_terminate` and
`unreachable` instruction. I assumed that because in LLVM very limited
forms of transformations are done to catchpads and cleanuppads to
maintain the scoping structure. But it turned out to be incorrect;
passes can merge cleanuppads into one, including terminate pads, as long
as the new code has a correct scoping structure. One pass that does this
I observed was `SimplifyCFG`, but there can be more. After this
transformation, a single cleanuppad can contain any number of other
instructions with the call to `__clang_call_terminate` and can span many
BBs. It wouldn't be practical to duplicate all these BBs within the
cleanuppad to generate the equivalent `catch_all` blocks, only with
calls to `__clang_call_terminate` replaced by calls to `std::terminate`.

Unless we do more complicated transformation to split those calls to
`__clang_call_terminate` into a separate cleanuppad, it is tricky to
solve.

---

Solution (?):

This CL just disables the generation and use of `__clang_call_terminate`
and calls `std::terminate()` directly in its place.

The possible downside of this approach can be, because the Itanium ABI
intended to "mark" the violating exception handled, we don't do that
anymore. What `__cxa_begin_catch` actually does is increment the
exception's handler count and decrement the uncaught exception count,
which in my opinion do not matter much given that we are about to
terminate the program anyway. Also it does not affect info like stack
traces that can be possibly shown to developers.

And while we use a variant of Itanium EH ABI, we can make some
deviations if we choose to; we are already different in that in the
current version of the EH spec we don't support two-phase unwinding. We
can possibly consider a more complicated transformation later to
reenable this, but I don't think that has high priority.

Changes in this CL contains:
- In Clang, we don't generate a call to `wasm.get.exception()` intrinsic
  and `__clang_call_terminate` function in terminate pads anymore; we
  simply generate calls to `std::terminate()`, which is the default
  implementation of `CGCXXABI::emitTerminateForUnexpectedException`.
- Remove `WebAssembly::ensureSingleBBTermPads() function and
  `WebAssemblyHandleEHTerminatePads` pass, because terminate pads are
  already `catch_all` now (because they don't need the exception
  pointer) and we don't need these transformations anymore.
- Change tests to use `std::terminate` directly. Also removes tests that
  tested `LateEHPrepare::ensureSingleBBTermPads` and
  `HandleEHTerminatePads` pass.
- Drive-by fix: Add some function attributes to EH intrinsic
  declarations

Fixes https://github.com/emscripten-core/emscripten/issues/13582.

Reviewed By: dschuff, tlively

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

3 years agoRevert "[Attributor] Enable heap-to-stack of any size"
William S. Moses [Thu, 4 Mar 2021 22:24:24 +0000 (17:24 -0500)]
Revert "[Attributor] Enable heap-to-stack of any size"

This reverts commit 51bd42ef9b870787afbeeffcd33adce765f70f23.

3 years ago[LoopVectorize] propagate fast-math-flags from induction instructions
Sanjay Patel [Thu, 4 Mar 2021 21:27:51 +0000 (16:27 -0500)]
[LoopVectorize] propagate fast-math-flags from induction instructions

This code assumed that FP math was only permissable if it was
fully "fast", so it hard-coded "fast" when creating new instructions.

The underlying code already allows matching recurrences/reductions
that are only "reassoc", so this change should prevent the potential
miscompile seen in the test diffs (we created "fast" ops even though
none existed in the original code).

I don't know if we need to create the temporary IRBuilder objects
used here, so that could be follow-up clean-up.

There's an open question about whether we should require "nsz" in
addition to "reassoc" here. InstCombine uses that combo for its
reassociative folds, but I think codegen is not as strict.

3 years ago[Attributor] Enable heap-to-stack of any size
William S. Moses [Tue, 2 Mar 2021 19:41:43 +0000 (14:41 -0500)]
[Attributor] Enable heap-to-stack of any size

Enable Attributor's heap-to-stack to lower unbounded allocations given a max size of -1

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

3 years ago[MS] Fix crash involving gnu stmt exprs and inalloca
Reid Kleckner [Thu, 4 Mar 2021 21:52:30 +0000 (13:52 -0800)]
[MS] Fix crash involving gnu stmt exprs and inalloca

Use a WeakTrackingVH to cope with the stmt emission logic that cleans up
unreachable blocks. This invalidates the reference to the deferred
replacement placeholder. Cope with it.

Fixes PR25102 (from 2015!)

3 years ago[NFC][AliasSetTracker] Remove implicit conversion AliasResult to integer.
dfukalov [Thu, 4 Mar 2021 20:17:49 +0000 (23:17 +0300)]
[NFC][AliasSetTracker] Remove implicit conversion AliasResult to integer.

Preparation to make AliasResult scoped enumeration.

Reviewed By: nikic

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

3 years ago[AMDGPU] Don't check for VMEM hazards on GFX10
Jay Foad [Wed, 3 Mar 2021 16:46:53 +0000 (16:46 +0000)]
[AMDGPU] Don't check for VMEM hazards on GFX10

The hazard where a VMEM reads an SGPR written by a VALU counts as a data
dependency hazard, so no nops are required on GFX10. Tested with Vulkan
CTS on GFX10.1 and GFX10.3.

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

3 years ago[gn build] Port d7834556b7ad
LLVM GN Syncbot [Thu, 4 Mar 2021 21:34:02 +0000 (21:34 +0000)]
[gn build] Port d7834556b7ad

3 years ago[gn build] port db06088d63f8
Nico Weber [Thu, 4 Mar 2021 21:33:24 +0000 (16:33 -0500)]
[gn build] port db06088d63f8

3 years ago[flang][fir][NFC] Update comments.
Eric Schweitz [Thu, 4 Mar 2021 21:30:16 +0000 (13:30 -0800)]
[flang][fir][NFC] Update comments.

3 years ago[MLIR][SPIRV] Rename `spv.globalVariable` to `spv.GlobalVariable`.
KareemErgawy-TomTom [Thu, 4 Mar 2021 21:17:12 +0000 (16:17 -0500)]
[MLIR][SPIRV] Rename `spv.globalVariable` to `spv.GlobalVariable`.

To unify the naming scheme across all ops in the SPIR-V dialect, we are
moving from spv.camelCase to spv.CamelCase everywhere.

Reviewed By: antiagainst

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

3 years ago[libcxx] [test] Use separate references for windows in the path.append test
Martin Storsjö [Thu, 15 Oct 2020 08:13:37 +0000 (11:13 +0300)]
[libcxx] [test] Use separate references for windows in the path.append test

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

3 years ago[MLIR][SPIRV] Rename `spv.constant` to `spv.Constant`.
KareemErgawy-TomTom [Thu, 4 Mar 2021 21:15:46 +0000 (16:15 -0500)]
[MLIR][SPIRV] Rename `spv.constant` to `spv.Constant`.

To unify the naming scheme across all ops in the SPIR-V dialect, we are
moving from `spv.camelCase` to `spv.CamelCase` everywhere.

Reviewed By: antiagainst

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

3 years ago[PowerPC] Disable more extended mne on AIX
Jinsong Ji [Thu, 4 Mar 2021 20:27:26 +0000 (20:27 +0000)]
[PowerPC] Disable more extended mne on AIX

To avoid assembler errors.

Reviewed By: sfertile

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

3 years ago[MLIR][SPIRV] Rename `spv.spcConstant...` to `spv.SpcConstant...`.
KareemErgawy-TomTom [Thu, 4 Mar 2021 21:01:28 +0000 (16:01 -0500)]
[MLIR][SPIRV] Rename `spv.spcConstant...` to `spv.SpcConstant...`.

To unify the naming scheme across all ops in the SPIR-V dialect, we are
moving from spv.camelCase to spv.CamelCase everywhere.

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

3 years ago[basicaa] Recurse through a single phi input
Philip Reames [Thu, 4 Mar 2021 21:03:54 +0000 (13:03 -0800)]
[basicaa] Recurse through a single phi input

BasicAA knows how to analyze phis, but to control compile time, we're fairly limited in doing so. This patch loosens that restriction just slightly when there is exactly one phi input (after discounting induction variable increments). The result of this is that we can handle more cases around nested and sibling loops with pointer induction variables.

A few points to note.
* This is deliberately extremely restrictive about recursing through at most one input of the phi.  There's a known general problem with BasicAA sometimes hitting exponential compile time already, and this patch makes every effort not to compound the problem.  Once the root issue is fixed, we can probably loosen the restrictions here a bit.
* As seen in the test file, we're still missing cases which aren't *directly* based on phis (e.g. using the indvar increment). I believe this to be a separate problem and am going to explore this in another patch once this one lands.
* As seen in the test file, this results in the unfortunate fact that using phivalues sometimes results in worse quality results. I believe this comes down to an oversight in how recursive phi detection was implemented for phivalues. I'm happy to tackle this in a follow up change.

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

3 years ago[mlir][IR][NFC] Move a majority of the builtin attributes to ODS
River Riddle [Thu, 4 Mar 2021 20:37:32 +0000 (12:37 -0800)]
[mlir][IR][NFC] Move a majority of the builtin attributes to ODS

Now that attributes can be generated using ODS, we can move the builtin attributes as well. This revision removes a majority of the builtin attributes with a few left for followup revisions. The attributes moved to ODS in this revision are: AffineMapAttr, ArrayAttr, DictionaryAttr, IntegerSetAttr, StringAttr, SymbolRefAttr, TypeAttr, and UnitAttr.

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

3 years ago[mlir][AttrDefGen] Add support for specifying the value type of an attribute
River Riddle [Thu, 4 Mar 2021 20:37:22 +0000 (12:37 -0800)]
[mlir][AttrDefGen] Add support for specifying the value type of an attribute

The value type of the attribute can be specified by either overriding the typeBuilder field on the AttrDef, or by providing a parameter of type `AttributeSelfTypeParameter`. This removes the need to define custom storage class constructors for attributes that have a value type other than NoneType.

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

3 years ago[libc++] Properly pick up the Ninja from Xcode in the CI script
Louis Dionne [Thu, 4 Mar 2021 21:01:36 +0000 (16:01 -0500)]
[libc++] Properly pick up the Ninja from Xcode in the CI script

3 years ago[dfsan] Increase coverage of vector and select tests
George Balatsouras [Thu, 4 Mar 2021 02:03:04 +0000 (18:03 -0800)]
[dfsan] Increase coverage of vector and select tests

Add more expectations in vector.ll and select.ll based on command-line option combinations.
Also, remove hard-coded shadow width references to enable fast8 transition.

Reviewed By: stephan.yichao.zhao

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

3 years ago[Remarks] Emit variable info in auto-init remarks
Francis Visoiu Mistrih [Mon, 1 Mar 2021 21:07:02 +0000 (13:07 -0800)]
[Remarks] Emit variable info in auto-init remarks

This enhances the auto-init remark with information about the variable
that is auto-initialized.

This is based of debug info if available, or alloca names (mostly for
development purposes).

```
auto-init.c:4:7: remark: Call to memset inserted by -ftrivial-auto-var-init. Memory operation size: 4096 bytes.Variables: var (4096 bytes). [-Rpass-missed=annotation-remarks]
  int var[1024];
      ^
```

This allows to see things like partial initialization of a variable that
the optimizer won't be able to completely remove.

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

3 years agoReland [GlobalISel] Start using vectors in GISelKnownBits
Petar Avramovic [Thu, 4 Mar 2021 13:27:39 +0000 (14:27 +0100)]
Reland [GlobalISel] Start using vectors in GISelKnownBits

This is recommit of 4c8fb7ddd6fa49258e0e9427e7345fb56ba522d4.
MIR in one unit test had mismatched types.

For vectors we consider a bit as known if it is the same for all demanded
vector elements (all elements by default). KnownBits BitWidth for vector
type is size of vector element. Add support for G_BUILD_VECTOR.
This allows combines of urem_pow2_to_mask in pre-legalizer combiner.

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

3 years agoRevert "[Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream"
Nicolas Guillemot [Thu, 4 Mar 2021 20:43:27 +0000 (12:43 -0800)]
Revert "[Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream"

This reverts commit 7479a2e00bc41f399942e5106fbdf9b4b0c11506.

This commit causes compile errors on clang-x64-windows-msvc, so I'm
reverting the patch for now.

For reference, the error in question is:

```
error C2280: 'llvm::raw_ostream_iterator<char,char>
&llvm::raw_ostream_iterator<char,char>::operator =(const
llvm::raw_ostream_iterator<char,char> &)': attempting to reference a deleted
function

note: compiler has generated 'llvm::raw_ostream_iterator<char,char>::operator ='
here

note: 'llvm::raw_ostream_iterator<char,char>
&llvm::raw_ostream_iterator<char,char>::operator =(const
llvm::raw_ostream_iterator<char,char> &)': function was implicitly deleted
because 'llvm::raw_ostream_iterator<char,char>' has a data member
'llvm::raw_ostream_iterator<char,char>::OutStream' of reference type
```

3 years ago[PPC] Silence unused variable warning in release builds. NFC.
Benjamin Kramer [Thu, 4 Mar 2021 20:43:19 +0000 (21:43 +0100)]
[PPC] Silence unused variable warning in release builds. NFC.

3 years ago[tests] Precommit tests for upcoming patch to support CSE of gc.relocates in gvn
Philip Reames [Thu, 4 Mar 2021 20:23:27 +0000 (12:23 -0800)]
[tests] Precommit tests for upcoming patch to support CSE of gc.relocates in gvn

3 years agoUse the right pass in test introduced in f1fdbd67
Philip Reames [Thu, 4 Mar 2021 20:21:13 +0000 (12:21 -0800)]
Use the right pass in test introduced in f1fdbd67

3 years ago[test] Add DCE coverage for gc.relocate
Philip Reames [Thu, 4 Mar 2021 20:16:25 +0000 (12:16 -0800)]
[test] Add DCE coverage for gc.relocate

3 years agoIntroduce noundef attribute at call sites for stricter poison analysis
Gui Andrade [Thu, 11 Feb 2021 02:34:01 +0000 (18:34 -0800)]
Introduce noundef attribute at call sites for stricter poison analysis

This change adds a new IR noundef attribute, which denotes when a function call argument or return val may never contain uninitialized bits.

In MemorySanitizer, this attribute enables optimizations which decrease instrumented code size by up to 17% (measured with an instrumented build of clang) . I'll introduce the change allowing msan to take advantage of this information in a separate patch.

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

3 years agoChange instrprof LLVM_VP_MAX_NUM_VALS_PER_SITE threshold.
Mitch Phillips [Thu, 4 Mar 2021 20:11:11 +0000 (12:11 -0800)]
Change instrprof LLVM_VP_MAX_NUM_VALS_PER_SITE threshold.

We're having flaky failures on this test on the sanitizer slow
buildbot. Not per-run flaky, but it'll be green for a while, then red
for a while. I suspect that changes in codegen are causing the
LLVM_VP_MAX_NUM_VALS_PER_SITE=150 to be above and below the limit
sporadically. The limit on my machine using lld and a non-bootstrapped
compiler is 175, but the bot uses GNU ld and ld.gold at different
points, which could be affecting behaviour.

Change this threshold to LLVM_VP_MAX_NUM_VALS_PER_SITE=130 in order to
try and get it below the failure point, at least for the foreseeable
future.

http://lab.llvm.org:8011/#/builders/37/builds/2744

3 years ago[tests] Expand coverage of gc.relocate CSE in early-cse
Philip Reames [Thu, 4 Mar 2021 20:12:45 +0000 (12:12 -0800)]
[tests] Expand coverage of gc.relocate CSE in early-cse

3 years ago[clang-tidy] Add options to describe individual core increments to readability-functi...
Jens Massberg [Thu, 4 Mar 2021 20:02:26 +0000 (21:02 +0100)]
[clang-tidy] Add options to describe individual core increments to readability-function-cognitive-complexity check.

Often you are only interested in the overall cognitive complexity of a
function and not every individual increment. Thus the flag
'DescribeBasicIncrements' is added. If it is set to 'true', each increment
is flagged. Otherwise, only the complexity of function with complexity
of at least the threshold are flagged.

By default 'DescribeBasisIncrements' is set to 'true', which is the original behavior of the check.

Added a new test for different flag combinations.

(The option to ignore macros which was original part of this patch will be added in another path)

Reviewed By: lebedev.ri

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

3 years ago[mlir] Add a DialectAsmParser::getChecked method
River Riddle [Thu, 4 Mar 2021 19:52:14 +0000 (11:52 -0800)]
[mlir] Add a DialectAsmParser::getChecked method

This function simplifies calling the getChecked methods on Attributes and Types from within the parser, and removes any need to use `getEncodedSourceLocation` for these methods (by using an SMLoc instead). This is much more efficient than using an mlir::Location, as the encoding process to produce an mlir::Location is inefficient and undesirable for parsing (locations used during parsing should not persist afterwards unless otherwise necessary).

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

3 years agoRevert "Revert "[Coverage] Emit gap region between statements if first statements...
Zequan Wu [Thu, 4 Mar 2021 19:50:31 +0000 (11:50 -0800)]
Revert "Revert "[Coverage] Emit gap region between statements if first statements contains terminate statements.""

Reland with update on test case ContinuousSyncmode/basic.c.

This reverts commit fe5c2c3ca682b140dd5e640e75948363b6b25ef9.

3 years ago[lld-macho] Include install name in error messages for dylibs from TBDs
Jez Ng [Thu, 4 Mar 2021 19:36:49 +0000 (14:36 -0500)]
[lld-macho] Include install name in error messages for dylibs from TBDs

Since multiple dylibs can be defined in one TBD, this is
necessary to avoid confusion.

Reviewed By: #lld-macho, oontvoo

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

3 years ago[lld-macho] Filter TAPI re-exports by target
Jez Ng [Thu, 4 Mar 2021 19:36:47 +0000 (14:36 -0500)]
[lld-macho] Filter TAPI re-exports by target

Previously, we were loading re-exports without checking whether
they were compatible with our target. Prior to {D97209}, it meant that
we were defining dylib symbols that were invalid -- usually a silent
failure unless our binary actually used them. D97209 exposed this as an
explicit error.

Along the way, I've extended our TAPI compatibility check to cover the
platform as well, instead of just checking the arch. To this end, I've
replaced MachO::Architecture with MachO::Target in our Config struct.

Reviewed By: #lld-macho, oontvoo

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

3 years ago[lld-macho] Fix & fold reexport-nested-libs test into stub-link.s
Jez Ng [Thu, 4 Mar 2021 19:36:46 +0000 (14:36 -0500)]
[lld-macho] Fix & fold reexport-nested-libs test into stub-link.s

The reexport-nested-libs test added in D97438 was a bit wonky.

First, it was linking against libReexportSystem.tbd which targets the
iOS simulator, and which in turn attempted to re-export the iOS
simulator's libSystem. However, due to the way `-syslibroot` works, it
was actually re-exporting the macOS libSystem.

As a result, the test was not actually able to resolve the symbols in
the desired libSystem. I'm guessing that @oontvoo was confused by this
and therefore included those symbols in libReexportSystem.tbd itself.
But this means that the test wasn't actually testing the resolution of
re-exported symbols (though it did at least verify that the re-exported
libraries could be located).

After some consideration, I figured that stub-link.s could be extended
to cover what reexport-nested-libs.s was attempting to do. The test
targets macOS, so we only have one `-syslibroot` and no chance of
confusion.

Reviewed By: #lld-macho, oontvoo

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

3 years ago[lld-macho] Bind re-exported symbols directly to implicitly-linked umbrellas
Jez Ng [Thu, 4 Mar 2021 19:36:44 +0000 (14:36 -0500)]
[lld-macho] Bind re-exported symbols directly to implicitly-linked umbrellas

Suppose we are linking against libFoo, which re-exports the
implicitly-bound libSystem, which in turn re-exports some
non-explicitly-bound library like `/usr/lib/system/libsystem_c.dylib`.
Then any bindings we have to a symbol in libsystem_c should use
libSystem (and not libFoo) as the umbrella library.

Reviewed By: #lld-macho, smeenai

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

3 years ago[llvm-ifs] Add option to use InterfaceStub library
Haowei Wu [Sat, 9 Jan 2021 00:26:32 +0000 (16:26 -0800)]
[llvm-ifs] Add option to use InterfaceStub library

This change adds '-use-interfacestub' option to allow llvm-ifs
to use InterfaceStub lib when generating ELF binary.

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

3 years ago[libc][NFC] Make few fenv functions work with fexcept_t from other libcs.
Siva Chandra Reddy [Thu, 4 Mar 2021 19:16:26 +0000 (11:16 -0800)]
[libc][NFC] Make few fenv functions work with fexcept_t from other libcs.

3 years ago[lldb/Interpreter] Make OptionGroupPythonClassWithDict options non-required
Med Ismail Bennani [Thu, 4 Mar 2021 19:23:56 +0000 (19:23 +0000)]
[lldb/Interpreter] Make OptionGroupPythonClassWithDict options non-required

When using `OptionGroupPythonClassWithDict` options in an `OptionGroup`
with other `Options`, it can happen that the combinaison of some options
of each group makes the command invalid.

To solve that issue, this patch adds a bitmask argument to the
`OptionGroupPythonClassWithDict` constuctor that is used to mark each
option as required (or not).

If the `required_options` bitmask isn't passed to the constructor, the
class will keep its default behaviour, making the `--script-class` and
`--python-function` required.

rdar://65508855

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
3 years ago[ObjC][ARC] Use operand bundle 'clang.arc.attachedcall' instead of
Akira Hatanaka [Wed, 10 Feb 2021 22:47:06 +0000 (14:47 -0800)]
[ObjC][ARC] Use operand bundle 'clang.arc.attachedcall' instead of
explicitly emitting retainRV or claimRV calls in the IR

This reapplies ed4718eccb12bd42214ca4fb17d196d49561c0c7, which was reverted
because it was causing a miscompile. The bug that was causing the miscompile
has been fixed in 75805dce5ff874676f3559c069fcd6737838f5c0.

Original commit message:

Background:

This fixes a longstanding problem where llvm breaks ARC's autorelease
optimization (see the link below) by separating calls from the marker
instructions or retainRV/claimRV calls. The backend changes are in
https://reviews.llvm.org/D92569.

https://clang.llvm.org/docs/AutomaticReferenceCounting.html#arc-runtime-objc-autoreleasereturnvalue

What this patch does to fix the problem:

- The front-end adds operand bundle "clang.arc.attachedcall" to calls,
  which indicates the call is implicitly followed by a marker
  instruction and an implicit retainRV/claimRV call that consumes the
  call result. In addition, it emits a call to
  @llvm.objc.clang.arc.noop.use, which consumes the call result, to
  prevent the middle-end passes from changing the return type of the
  called function. This is currently done only when the target is arm64
  and the optimization level is higher than -O0.

- ARC optimizer temporarily emits retainRV/claimRV calls after the calls
  with the operand bundle in the IR and removes the inserted calls after
  processing the function.

- ARC contract pass emits retainRV/claimRV calls after the call with the
  operand bundle. It doesn't remove the operand bundle on the call since
  the backend needs it to emit the marker instruction. The retainRV and
  claimRV calls are emitted late in the pipeline to prevent optimization
  passes from transforming the IR in a way that makes it harder for the
  ARC middle-end passes to figure out the def-use relationship between
  the call and the retainRV/claimRV calls (which is the cause of
  PR31925).

- The function inliner removes an autoreleaseRV call in the callee if
  nothing in the callee prevents it from being paired up with the
  retainRV/claimRV call in the caller. It then inserts a release call if
  claimRV is attached to the call since autoreleaseRV+claimRV is
  equivalent to a release. If it cannot find an autoreleaseRV call, it
  tries to transfer the operand bundle to a function call in the callee.
  This is important since the ARC optimizer can remove the autoreleaseRV
  returning the callee result, which makes it impossible to pair it up
  with the retainRV/claimRV call in the caller. If that fails, it simply
  emits a retain call in the IR if retainRV is attached to the call and
  does nothing if claimRV is attached to it.

- SCCP refrains from replacing the return value of a call with a
  constant value if the call has the operand bundle. This ensures the
  call always has at least one user (the call to
  @llvm.objc.clang.arc.noop.use).

- This patch also fixes a bug in replaceUsesOfNonProtoConstant where
  multiple operand bundles of the same kind were being added to a call.

Future work:

- Use the operand bundle on x86-64.

- Fix the auto upgrader to convert call+retainRV/claimRV pairs into
  calls with the operand bundles.

rdar://71443534

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

3 years ago[Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream
Nicolas Guillemot [Thu, 4 Mar 2021 17:58:16 +0000 (09:58 -0800)]
[Support] Add raw_ostream_iterator: ostream_iterator for raw_ostream

Adds a class `raw_ostream_iterator` that behaves like
std::ostream_iterator, but can be used with raw_ostream.
This is useful for using raw_ostream with std algorithms.

For example, it can be used to output std containers as follows:

```
std::vector<int> V = { 1, 2, 3 };
std::copy(V.begin(), V.end(), raw_ostream_iterator<int>(outs(), ", "));
// Output: "1, 2, 3, "
```

The API tries to follow std::ostream_iterator as closely as is
practically possible.

Reviewed By: dblaikie, mkitzan

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

3 years agoImprove the debug info for coro-split .resume functions
Adrian Prantl [Fri, 26 Feb 2021 01:25:34 +0000 (17:25 -0800)]
Improve the debug info for coro-split .resume functions

This patch updates the scope line to point to the suspend point. This
makes the first address in the function point to the first source line
in the resume function rather than the function declaration. Without
this the line table "jumps" from the beginning of the function to the
suspend point at the beginning.

rdar://73386346

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

3 years ago[clang-tidy] Extend LoopConvert on array with `!=` comparison
Nathan James [Thu, 4 Mar 2021 18:58:42 +0000 (18:58 +0000)]
[clang-tidy] Extend LoopConvert on array with `!=` comparison

Enables transforming loops of the form:
```
for (int i = 0; I != container.size(); ++I) { container[I]...; }
for (int i = 0; I != N; ++I) { FixedArrSizeN[I]...; }
```

Reviewed By: aaron.ballman

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

3 years ago[CostModel][SVE] Add cost model for shuffle reverse with i1 and scalable vector
Caroline Concatto [Mon, 15 Feb 2021 17:46:21 +0000 (17:46 +0000)]
[CostModel][SVE]  Add cost model for shuffle reverse with i1 and scalable vector

This patch adds the cost model for experimental.vector.reverse
with scalable vector types: nxv16i1, nxv8i1, nxv4i1 and nxv2i1.
These types are missing from the previous cost model patch D95603.

The cost model for experimental.vector.reverse with 1 bit mask is used by
loop vectorization in the patch D95363

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

3 years ago[TableGen] Fix warning when compiling generated MCCodeEmitter
Jay Foad [Thu, 4 Mar 2021 13:53:51 +0000 (13:53 +0000)]
[TableGen] Fix warning when compiling generated MCCodeEmitter

This fixes an instance of:
warning: cast from 'const unsigned long *' to 'unsigned char *' drops const qualifier [-Wcast-qual]
when compiling the generated MCCodeEmitter for an out-of-tree target
that uses the optional support for instruction widths > 64 bits.

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

3 years ago[mir] Fix confusing MIR when MMO's value is nullptr but offset is non-zero
Daniel Sanders [Tue, 2 Mar 2021 22:59:06 +0000 (14:59 -0800)]
[mir] Fix confusing MIR when MMO's value is nullptr but offset is non-zero

:: (store 1 + 4, addrspace 1)
->
:: (store 1 into undef + 4, addrspace 1)

An offset without a base isn't terribly useful but it's convenient to update
the offset without checking the value. For example, when breaking apart
stores into smaller units

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

3 years ago[PowerPC][PC Rel] Implement option to omit Power10 instructions from stubs
Albion Fung [Thu, 4 Mar 2021 18:17:40 +0000 (13:17 -0500)]
[PowerPC][PC Rel] Implement option to omit Power10 instructions from stubs

Implemented the option to omit Power10 instructions from save stubs via the
option --no-power10-stubs or --power10-stubs=no on lld. --power10-stubs= will
override the other option. --power10-stubs=auto also exists to use the default
behaviour (ie allow Power10 instructions in stubs).

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

3 years ago[cgp] Defer lazy domtree usage to last possible point
Philip Reames [Thu, 4 Mar 2021 18:18:10 +0000 (10:18 -0800)]
[cgp] Defer lazy domtree usage to last possible point

This is a compile time optimization for d9e93e8e5. Not sure this matters or not, but why not do it just in case.

This does involve querying TLI with a potentially invalid addressing mode for the using instruction, but since we don't actually pass the using instruction to the TLI callback, that should be fine.

3 years agoFold full-size subview of static shapes.
Ahmed Taei [Thu, 25 Feb 2021 01:24:14 +0000 (17:24 -0800)]
Fold full-size subview of static shapes.

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

3 years ago[mlir] Tighten the rules around folding TensorLoadOp
Nicolas Vasilache [Thu, 4 Mar 2021 17:36:56 +0000 (17:36 +0000)]
[mlir] Tighten the rules around folding TensorLoadOp

`tensor_load(tensor_to_memref(x)) -> x` is an incorrect folding because it ignores potential aliasing.

This revision approximates no-aliasing by restricting the folding to occur only when tensor_to_memref
is immediately preceded by tensor_load in the same block. This is a conservative step back towards
correctness until better alias analysis becomes available.

Context: https://llvm.discourse.group/t/properly-using-bufferization-related-passes/2913/6

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

3 years ago[FileCheck][NFC] Move -dump-input tests to a subdirectory
Joel E. Denny [Thu, 4 Mar 2021 17:43:48 +0000 (12:43 -0500)]
[FileCheck][NFC] Move -dump-input tests to a subdirectory

Just to make them easier to find.

Reviewed By: jhenderson

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

3 years ago[CGP] Lazily compute domtree only when needed during address matching
Philip Reames [Thu, 4 Mar 2021 17:31:02 +0000 (09:31 -0800)]
[CGP] Lazily compute domtree only when needed during address matching

This is a compile time optimization for d9e93e8e5.  As pointed out in post dommit review on the original review (D96399), there was a moderately large compile time regression with this patch and the eager computation of domtree on matcher construction is the first obvious candidate for why.

3 years ago[mlir] Add an AccessGroup attribute to load/store LLVM dialect ops and generate the...
Arpith C. Jacob [Thu, 4 Mar 2021 17:12:56 +0000 (18:12 +0100)]
[mlir] Add an AccessGroup attribute to load/store LLVM dialect ops and generate the access_group LLVM metadata.

This also includes LLVM dialect ops created from intrinsics.

Reviewed By: ftynse

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

3 years ago[OpenMP] Encapsulate more in checkDeviceAndCtors
Joel E. Denny [Thu, 4 Mar 2021 16:19:13 +0000 (11:19 -0500)]
[OpenMP] Encapsulate more in checkDeviceAndCtors

This patch just encapsulates some repeated code.  To do so, it
relocates some functions from interface.cpp to omptarget.cpp.  It also
adjusts them to the LLVM coding style.

This patch is almost NFC except some `DP` messages are a bit
different.  For example, messages like "Entering target region" are
now emitted even if offload is disabled, but a subsequent "Offload is
disabled" is then emitted.

Reviewed By: jdoerfert, grokos

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

3 years ago[OpenMP] Fix lone target exit data
Joel E. Denny [Thu, 4 Mar 2021 16:18:13 +0000 (11:18 -0500)]
[OpenMP] Fix lone target exit data

Without this patch, an `omp target exit data` before the runtime is
initialized produces a runtime error.  This patch fixes that by
changing `__tgt_target_data_end_mapper` to call `CheckDeviceAndCtors`
like many other runtime routines.

Discussed at
<https://lists.llvm.org/pipermail/openmp-dev/2021-March/003920.html>.

Reviewed By: grokos

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

3 years ago[OpenMP] Fix support for device as host
Joel E. Denny [Thu, 4 Mar 2021 16:15:58 +0000 (11:15 -0500)]
[OpenMP] Fix support for device as host

Without this patch, when the offload device is set to
`omp_get_initial_device()`, the runtime fails with an error diagnostic
when entering target regions or target data regions.

However, OpenMP 5.1, sec. 2.14.5 "target Construct", "Restrictions",
p. 203, L3-5 states:

> The device clause expression must evaluate to a non-negative integer
> value that is less than or equal to the value of
> omp_get_num_devices().

Sec. 3.7.7 "omp_get_initial_device", p. 412, L2-3 states:

> The value of the device number is the value returned by the
> omp_get_num_devices routine.

Similarly, OpenMP 5.0, sec. 2.12.5 "target Construct", "Restrictions",
p. 174 L30-32 states:

> The device clause expression must evaluate to a non-negative integer
> value less than the value of omp_get_num_devices() or to the value
> of omp_get_initial_device().

This patch fixes this behavior by changing the runtime to behave as if
offloading is disabled whenever it finds the offload device (either
from a `device` clause or the default device) is set to the host
device.  In the case of mandatory offloading when
`omp_get_num_devices() == 0`, it incorporates the behavior proposed
for OpenMP 5.2 in OpenMP spec github issue 2669.

Reviewed By: grokos, RaviNarayanaswamy

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

3 years ago[clang] removes check against integral-to-pointer conversion...
Christopher Di Bella [Fri, 26 Feb 2021 00:11:25 +0000 (00:11 +0000)]
[clang] removes check against integral-to-pointer conversion...

... unless it's a literal

D94640 was a bit too aggressive in its analysis, considering integers
representing valid addresses as invalid. This change rolls back some of
the check, so that only the most obvious case is still flagged.

Before:

```cpp
free((void*)1000);   // literal converted to `void*`: warning good
free((void*)an_int); // `int` object converted to `void*`: warning might
                     //  be a false positive
```

After

```cpp
free((void*)1000);   // literal converted to `void*`: warning good
free((void*)an_int); // doesn't warn
```

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

3 years ago[dfsan] add a missing zero origin at atomic commands
Jianzhou Zhao [Thu, 4 Mar 2021 16:48:06 +0000 (16:48 +0000)]
[dfsan] add a missing zero origin at atomic commands

3 years agoRevert "[llvm-exegesis] Disable the LBR check on AMD"
Nico Weber [Thu, 4 Mar 2021 16:48:33 +0000 (11:48 -0500)]
Revert "[llvm-exegesis] Disable the LBR check on AMD"

This reverts commit 293e8fa13d3f05e993771577a4c022deee5cbf6e.
Breaks build on non-intel hosts, see e.g.
http://45.33.8.238/macm1/4600/step_3.txt

3 years ago[gn build] port e9f9ec837d447857
Nico Weber [Thu, 4 Mar 2021 16:40:12 +0000 (11:40 -0500)]
[gn build] port e9f9ec837d447857

3 years ago[CMake][AIX] Adjust plugin library extension used on AIX
Xiangling Liao [Thu, 4 Mar 2021 14:52:04 +0000 (09:52 -0500)]
[CMake][AIX] Adjust plugin library extension used on AIX

As stated in the CMake manual, we are supposed to use MODULE rules to generate
plugin libraries:

"MODULE libraries are plugins that are not linked into other targets but may be
loaded dynamically at runtime using dlopen-like functionality"

Besides, LLVM's plugin infrastructure fits with the AIX treatment of .so
shared objects more than it fits with the AIX treatment of .a library archives
(which may contain shared objects).

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

3 years ago[llvm-exegesis] Disable the LBR check on AMD
Vy Nguyen [Thu, 25 Feb 2021 22:40:38 +0000 (17:40 -0500)]
[llvm-exegesis] Disable the LBR check on AMD

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

The bug reported a hang (or very very slow runtime) on a Zen2. Unfortunately, we don't have the hardware right now to debug it and I was not able to reproduce the bug on a HSW.
Theory we've got is that the lbr-checking code could be confused on AMD.

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

3 years ago[Instcombiner]Improve emission of logical or/and reductions.
Alexey Bataev [Mon, 22 Feb 2021 20:56:09 +0000 (12:56 -0800)]
[Instcombiner]Improve emission of logical or/and reductions.

For logical or/and reductions we emit regular intrinsics @llvm.vector.reduce.or/and.vxi1 calls.
These intrinsics are not effective for the logical or/and reductions,
especially if the optimizer is able to emit short circuit versions of
the scalar or/and instructions and vector code gets less effective than
the scalar version.
Instead, or reduction for i1 can be represented as:
```
%val = bitcast <ReduxWidth x i1> to iReduxWidth
%res = cmp ne iReduxWidth %val, 0
```
and reduction for i1 can be represented as:
```
%val = bitcast <ReduxWidth x i1> to iReduxWidth
%res = cmp eq iReduxWidth %val, 11111
```
This improves perfromance of the vector code significantly and make it
to outperform short circuit scalar code.

Part of D57059.

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

3 years ago[PowerPC][AIX] Handle variadic vector formal arguments.
Sean Fertile [Thu, 4 Mar 2021 15:56:53 +0000 (10:56 -0500)]
[PowerPC][AIX] Handle variadic vector formal arguments.

Patch adds support for passing vector arguments to variadic functions.
Arguments which are fixed shadow GPRs and stack space even when they are
passed in vector registers, while arguments passed through ellipses are
passed in(properly aligned GPRs if available and on the stack once all
GPR arguments registers are consumed.

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

3 years ago[Analysis][LoopVectorize] rename "Unsafe" variables/methods; NFC
Sanjay Patel [Thu, 4 Mar 2021 15:06:24 +0000 (10:06 -0500)]
[Analysis][LoopVectorize] rename "Unsafe" variables/methods; NFC

Similar to b3a33553aec7, but this shows a TODO and a potential
miscompile is already present.

We are tracking an FP instruction that does *not* have FMF (reassoc)
properties, so calling that "Unsafe" seems opposite of the common
reading.

I also removed one getter method by rolling the null check into
the access. Further simplification may be possible.

The motivation is to clean up the interactions between FMF and
function-level attributes in these classes and their callers.

The new test shows that there is an existing bug somewhere in
the callers. We assumed that the original code was fully 'fast'
and so we produced IR with 'fast' even though it was just 'reassoc'.