2 days agoMerge branch 'addmainunit4-altlink-sharedstmt-dieref-dwz3-testcategory-testcase'... dwz
Jan Kratochvil [Fri, 5 Mar 2021 14:59:25 +0000 (15:59 +0100)]
Merge branch 'addmainunit4-altlink-sharedstmt-dieref-dwz3-testcategory-testcase' into addmainunit4-altlink-sharedstmt-dieref-dwz3-testcategory-testcase-symlink

2 days agoMerge branch 'addmainunit4-altlink-sharedstmt-dieref-dwz3-testcategory' into addmainu...
Jan Kratochvil [Fri, 5 Mar 2021 14:59:22 +0000 (15:59 +0100)]
Merge branch 'addmainunit4-altlink-sharedstmt-dieref-dwz3-testcategory' into addmainunit4-altlink-sharedstmt-dieref-dwz3-testcategory-testcase

2 days agoMerge branch 'addmainunit4-altlink-sharedstmt-dieref-dwz3' into addmainunit4-altlink...
Jan Kratochvil [Fri, 5 Mar 2021 14:59:19 +0000 (15:59 +0100)]
Merge branch 'addmainunit4-altlink-sharedstmt-dieref-dwz3' into addmainunit4-altlink-sharedstmt-dieref-dwz3-testcategory

2 days agoMerge branch 'addmainunit4-altlink-sharedstmt-dieref' into addmainunit4-altlink-share...
Jan Kratochvil [Fri, 5 Mar 2021 14:59:13 +0000 (15:59 +0100)]
Merge branch 'addmainunit4-altlink-sharedstmt-dieref' into addmainunit4-altlink-sharedstmt-dieref-dwz3

2 days agoMerge branch 'addmainunit4-altlink-sharedstmt' into addmainunit4-altlink-sharedstmt...
Jan Kratochvil [Fri, 5 Mar 2021 14:57:35 +0000 (15:57 +0100)]
Merge branch 'addmainunit4-altlink-sharedstmt' into addmainunit4-altlink-sharedstmt-dieref

2 days agoMerge branch 'addmainunit4-altlink' into addmainunit4-altlink-sharedstmt
Jan Kratochvil [Fri, 5 Mar 2021 14:57:31 +0000 (15:57 +0100)]
Merge branch 'addmainunit4-altlink' into addmainunit4-altlink-sharedstmt

2 days agoMerge branch 'addmainunit4' into addmainunit4-altlink
Jan Kratochvil [Fri, 5 Mar 2021 14:57:27 +0000 (15:57 +0100)]
Merge branch 'addmainunit4' into addmainunit4-altlink

2 days agoMerge remote-tracking branch 'origin/main' into addmainunit4
Jan Kratochvil [Fri, 5 Mar 2021 14:57:24 +0000 (15:57 +0100)]
Merge remote-tracking branch 'origin/main' into addmainunit4

2 days ago[libcxxabi] Add LIBCXXABI_HAS_WIN32_THREAD_API build option
Markus Böck [Fri, 5 Mar 2021 14:30:13 +0000 (15:30 +0100)]
[libcxxabi] Add LIBCXXABI_HAS_WIN32_THREAD_API build option

A few files in libc++abi make use of libc++ headers and a few of those use threading primitives provided by libc++. Since libc++ has multiple threading APIs it may be necessary to override auto-detection.

This patch adds the LIBCXXABI_HAS_WIN32_THREAD_API which does roughly the same as LIBCXXABI_HAS_PTHREAD_API and the similarly named LIBCXX_HAS_WIN32_THREAD_API from libc++. Instead of using autodetection it will force the use of win32 threads instead of pthreads in headers included from libc++.

Without this patch, libc++abi may depend on pthreads if present on the users build environment, even if win32 threading was selected for libc++.

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

2 days ago[XCOFF][DWARF] set default DWARF version to 3.
Chen Zheng [Fri, 5 Mar 2021 14:20:48 +0000 (09:20 -0500)]
[XCOFF][DWARF] set default DWARF version to 3.

Reviewed By: jsji

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

2 days ago[lld/mac] minor formatting tweak to test just added in 0e319bd0be2
Nico Weber [Fri, 5 Mar 2021 14:16:55 +0000 (09:16 -0500)]
[lld/mac] minor formatting tweak to test just added in 0e319bd0be2

whitespace only, no behavior change

2 days ago[lld/mac] ad-hoc sign dylibs and bundles on arm64 by default, support -(no_)adhoc_cod...
Nico Weber [Fri, 5 Mar 2021 14:07:58 +0000 (09:07 -0500)]
[lld/mac] ad-hoc sign dylibs and bundles on arm64 by default, support -(no_)adhoc_codesign flags

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

2 days ago[BPF] Add support for floats and doubles
Ilya Leoshkevich [Fri, 5 Mar 2021 13:29:57 +0000 (14:29 +0100)]
[BPF] Add support for floats and doubles

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

Reviewed By: yonghong-song

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

2 days ago[clang-tidy] Use-after-move: Ignore moves inside a try_emplace.
Martin Boehme [Fri, 5 Mar 2021 12:16:00 +0000 (13:16 +0100)]
[clang-tidy] Use-after-move: Ignore moves inside a try_emplace.

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

2 days ago[HIP] do not use -munsafe-fp-atomics by default
Yaxun (Sam) Liu [Thu, 4 Mar 2021 18:15:54 +0000 (13:15 -0500)]
[HIP] do not use -munsafe-fp-atomics by default

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

2 days ago[HIP] do not use -mconstructor-aliases for device
Yaxun (Sam) Liu [Wed, 3 Mar 2021 21:42:57 +0000 (16:42 -0500)]
[HIP] do not use -mconstructor-aliases for device

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

2 days ago[OpenCL] Fix `mix` builtin overloads
Sven van Haastregt [Fri, 5 Mar 2021 13:43:30 +0000 (13:43 +0000)]
[OpenCL] Fix `mix` builtin overloads

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

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.

2 days ago[clang-format] Improve clang-format-diff.py error message
David Spickett [Fri, 5 Mar 2021 11:13:58 +0000 (11:13 +0000)]
[clang-format] Improve clang-format-diff.py error message

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

2 days agoReapply "[DebugInfo] Add new instruction and DIExpression operator for variadic...
Stephen Tozer [Thu, 4 Mar 2021 12:02:28 +0000 (12:02 +0000)]
Reapply  "[DebugInfo] Add new instruction and DIExpression operator for variadic debug values"

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

2 days ago[test] Use host platform specific error message substitution in lit tests
Abhina Sreeskantharajan [Fri, 5 Mar 2021 12:20:51 +0000 (07:20 -0500)]
[test] Use host platform specific error message substitution in lit tests

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

2 days ago[AMDGPU] Keep skip branch for ds instructions
Sebastian Neubauer [Thu, 4 Mar 2021 09:39:42 +0000 (10:39 +0100)]
[AMDGPU] Keep skip branch for ds instructions

Same as other memory instructions, ds instructions add latency even if
exec is zero. Jumping over them if exec=0 is cheaper than executing
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

2 days ago[AArch64] Add missing intrinsics for vrnd
Jingu Kang [Thu, 4 Mar 2021 14:40:01 +0000 (14:40 +0000)]
[AArch64] Add missing intrinsics for vrnd

2 days agoFix Wdocumentation unknown parameter warning. NFCI.
Simon Pilgrim [Fri, 5 Mar 2021 11:23:49 +0000 (11:23 +0000)]
Fix Wdocumentation unknown parameter warning. NFCI.

2 days ago[gn build] Port a60d06d8b757
LLVM GN Syncbot [Fri, 5 Mar 2021 11:09:38 +0000 (11:09 +0000)]
[gn build] Port a60d06d8b757

2 days agoRevert rG8198d83965ba4b9db6922b44ef3041030b2bac39: "[X86] Pass to transform amx intri...
Simon Pilgrim [Fri, 5 Mar 2021 10:52:42 +0000 (10:52 +0000)]
Revert rG8198d83965ba4b9db6922b44ef3041030b2bac39: "[X86] Pass to transform amx intrinsics to scalar operation."

This reverts commit 8198d83965ba4b9db6922b44ef3041030b2bac39.due to buildbot breakages

2 days ago[X86] X86ISelLowering.cpp - try to use for-range loops. NFCI.
Simon Pilgrim [Thu, 4 Mar 2021 18:53:07 +0000 (18:53 +0000)]
[X86] X86ISelLowering.cpp - try to use for-range loops. NFCI.

2 days ago[lld][WebAssembly] Allow element sections for nonzero table numbers
Andy Wingo [Thu, 4 Mar 2021 09:33:11 +0000 (10:33 +0100)]
[lld][WebAssembly] Allow element sections for nonzero table numbers

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

2 days ago[test] Fix new CodeGenPrepare test for non-X86 systems
Jann Horn [Fri, 5 Mar 2021 10:48:37 +0000 (11:48 +0100)]
[test] Fix new CodeGenPrepare test for non-X86 systems

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

Reviewed By: bkramer

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

2 days ago[WebAssembly][yaml2obj][obj2yaml] Elem sections for nonzero tables
Andy Wingo [Thu, 4 Mar 2021 09:30:00 +0000 (10:30 +0100)]
[WebAssembly][yaml2obj][obj2yaml] Elem sections for nonzero tables

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

2 days ago[clang][modules] Use extensible RTTI for ModuleFileExtension
Jan Svoboda [Mon, 1 Mar 2021 17:52:15 +0000 (18:52 +0100)]
[clang][modules] Use extensible RTTI for ModuleFileExtension

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

2 days agoReland AMDGPU/GlobalISel: Combine zext(trunc x) to x after RegBankSelect
Petar Avramovic [Thu, 4 Mar 2021 13:40:31 +0000 (14:40 +0100)]
Reland AMDGPU/GlobalISel: Combine zext(trunc x) to x after RegBankSelect

Recommit bf5a5826504754788a8f1e3fec7a7dc95cda5782. Depends on
4c8fb7ddd6fa49258e0e9427e7345fb56ba522d4 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

2 days agoReland [GlobalISel] Combine zext(trunc x) to x
Petar Avramovic [Thu, 4 Mar 2021 13:34:21 +0000 (14:34 +0100)]
Reland [GlobalISel] Combine zext(trunc x) to x

Recommit 4112299ee761a9b6a309c8ff4a7e75f8c8d8851b. Depends on
4c8fb7ddd6fa49258e0e9427e7345fb56ba522d4 which was reverted.

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

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

2 days ago[SVE][LoopVectorize] Add support for extracting the last lane of a scalable vector
David Sherwood [Fri, 15 Jan 2021 14:12:50 +0000 (14:12 +0000)]
[SVE][LoopVectorize] Add support for extracting the last lane of a scalable vector

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

2 days ago[clang][cli] Fix generation of '-fvisibility' with regards to '-mignore-xcoff-visibility'
Jan Svoboda [Fri, 26 Feb 2021 14:11:11 +0000 (15:11 +0100)]
[clang][cli] Fix generation of '-fvisibility' with regards to '-mignore-xcoff-visibility'

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

2 days ago[mlir][scf] Canonicalize scf.for last tensor iteration result.
Nicolas Vasilache [Thu, 4 Mar 2021 21:52:05 +0000 (21:52 +0000)]
[mlir][scf] Canonicalize scf.for last tensor iteration result.

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`

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

2 days ago[libc++] [C++2b] [P1682] Add to_underlying.
Marek Kurdej [Fri, 5 Mar 2021 08:19:39 +0000 (09:19 +0100)]
[libc++] [C++2b] [P1682] Add to_underlying.

* https://wg21.link/P1682

Reviewed By: ldionne, Mordante, #libc

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

2 days ago[clangd] Rename Module -> FeatureModule to avoid confusion. NFC
Sam McCall [Thu, 4 Mar 2021 15:21:01 +0000 (16:21 +0100)]
[clangd] Rename Module -> FeatureModule to avoid confusion. NFC

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

2 days ago[llvm-objcopy] Fix crash for binary input files with non-ascii names
James Henderson [Tue, 23 Feb 2021 15:32:45 +0000 (15:32 +0000)]
[llvm-objcopy] Fix crash for binary input files with non-ascii names

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

2 days ago[llvm-objcopy][test] Fix test that could have passed spuriously
James Henderson [Thu, 25 Feb 2021 15:50:48 +0000 (15:50 +0000)]
[llvm-objcopy][test] Fix test that could have passed spuriously

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

2 days ago[profile][test] Pin Linux/instrprof-value-prof-warn.test to -fuse-ld=bfd
Fangrui Song [Fri, 5 Mar 2021 08:52:25 +0000 (00:52 -0800)]
[profile][test] Pin Linux/instrprof-value-prof-warn.test to -fuse-ld=bfd

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

2 days ago[libcxx] Map ERROR_BAD_PATHNAME to errc::no_such_file_or_directory on windows
Martin Storsjö [Sat, 27 Feb 2021 14:09:49 +0000 (16:09 +0200)]
[libcxx] Map ERROR_BAD_PATHNAME to errc::no_such_file_or_directory on windows

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

2 days ago[libcxx] Avoid infinite recursion in create_directories, if the root directory doesn...
Martin Storsjö [Sat, 27 Feb 2021 17:12:25 +0000 (19:12 +0200)]
[libcxx] Avoid infinite recursion in create_directories, if the root directory doesn't exist

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

2 days 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

2 days 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

2 days 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

2 days 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

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

2 days 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

2 days 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

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

2 days 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

2 days 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
* replaces a few uses of `auto`

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

2 days 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.

2 days 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

2 days 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.

2 days 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

2 days 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

2 days 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 days 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 days 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 days 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 days 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

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

   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 days 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 days 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 days ago[gn build] port b973e2e2f27e
Nico Weber [Thu, 4 Mar 2021 23:40:52 +0000 (18:40 -0500)]
[gn build] port b973e2e2f27e

3 days 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 days 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 days 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 days 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 days 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 {
} 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 days ago[gn build] Port 561abd83ffec
LLVM GN Syncbot [Thu, 4 Mar 2021 22:58:35 +0000 (22:58 +0000)]
[gn build] Port 561abd83ffec

3 days 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


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) {
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`
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)
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)
call @std::terminate()
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.



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


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

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

Reviewed By: dschuff, tlively

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

3 days 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 days 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 days 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 days 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 days 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 days 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 days ago[gn build] Port d7834556b7ad
LLVM GN Syncbot [Thu, 4 Mar 2021 21:34:02 +0000 (21:34 +0000)]
[gn build] Port d7834556b7ad

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

3 days 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 days 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 days 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 days 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 days 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 days 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 days 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 days 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 days 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 days 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 days 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 days 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 days 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 days 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

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

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