Refactored the code and separated out a function
`canSafelyUnrollMultiExitLoop` to reduce redundant checks and make it
easier to add profitability heuristics later.
Added tests to runtime unrolling to make sure that unrolling for
multi-exit loops is not done unless the option
-unroll-runtime-multi-exit is true.

llvm-svn: 307843

Summary:
isFusion returns true if the subtarget supports any kind of instruction
fusion, similar to ARMSubtarget::isFusion. This was suggested in D34142.

This changes the current behavior slightly, because the macro fusion mutation 
is now added to the PostRA MachineScheduler in case the subtarget supports
any kind of fusion. I think that makes sense because if the PostRA 
MachineScheduler is run, there is potential that instructions scheduled back to 
back are re-scheduled.

Reviewers: evandro, t.p.northover, joelkevinjones, joel_k_jones, steleman

Reviewed By: joelkevinjones

Subscribers: joel_k_jones, aemerson, rengolin, javed.absar, kristof.beyls, llvm-commits

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

llvm-svn: 307842

Summary:
Element atomic intrinsicAtomic instructions are not yet supported in WebAssembly, so we mark them as     
unsupported for the moment.

Reviewers: sunfish, dschuff, sbc100

Reviewed By: dschuff, sbc100

Subscribers: jfb, sbc100, jgravelle-google

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

llvm-svn: 307841

Where is is needed (at the end of headers that define it), be
consistent about its use.

Also fix a few header guards that I found in the process.

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

llvm-svn: 307840

llvm-svn: 307839

Corrected several typos and incorrect parameters description that Sony
's techinical writer found during review.

I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream.

llvm-svn: 307838

This fixes PR33706.
Differential Revision: https://reviews.llvm.org/D35227

llvm-svn: 307837

Unlike many other instructions, these instructions have aliases which
take coprocessor registers, gpr register, accumulator (and dsp accumulator)
registers, floating point registers, floating point control registers and
coprocessor 2 data and control operands.

For the moment, these aliases are treated as pseudo instructions which are
expanded into the underlying instruction. As a result, disassembling these
instructions shows the underlying instruction and not the alias.

Reviewers: slthakur, atanasyan

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

llvm-svn: 307836

Some C++14 features slipped in along with an extra member qualification.

llvm-svn: 307835

Summary:
There is a reserved range of type indexes for built-in types (like integers).
This will create a symbol for a built-in type if the caller askes for one by
type index.  This is also plumbing for being able to recall symbols by type
index in general, but user-defined types will come in subsequent patches.

Reviewers: rnk, zturner

Subscribers: mgorny, hiraditya, llvm-commits

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

llvm-svn: 307834

Summary: Generate more IntSymExpr constraints, perform SVal simplification for IntSymExpr and SymbolCast constraints, and create fully symbolic SymExprs

Reviewers: zaks.anna, dcoughlin, NoQ, xazax.hun

Subscribers: mgorny, cfe-commits

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

llvm-svn: 307833

Add Fuchsia support to some builtings and avoid building builtins
that are not and will never be used on Fuchsia.

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

llvm-svn: 307832

Summary:
 Revision 307796 caused an internal build break in WebAssembly bots in the form of a
crash.  ex:
Here's the crash dump from one of the failing tests:

/usr/local/google/home/blaikie/dev/llvm/build/default/./bin/llc < /usr/local/google/home/blaikie/dev/llvm/src/test/CodeGen/WebAssembly/global.ll -asm-verbose=false -disable-wasm-fallthrough-return-opt -disable-wasm-explicit-locals | /usr/local/google/home/blaikie/dev/llvm/build/default/./bin/FileCheck /usr/local/google/home/blaikie/dev/llvm/src/test/CodeGen/WebAssembly/global.ll
--
Exit Code: 2

Command Output (stderr):
--
Stack dump:
0.      Program arguments: build/default/./bin/llc -asm-verbose=false -disable-wasm-fallthrough-return-opt -disable-wasm-explicit-locals
1.      Running pass 'Function Pass Manager' on module '<stdin>'.
2.      Running pass 'WebAssembly Assembly Printer' on function '@call_memcpy'
FileCheck error: '-' is empty.
FileCheck command line:  build/default/./bin/FileCheck src/test/CodeGen/WebAssembly/global.ll

The problem is in lib/Target/WebAssembly/WebAssemblyRuntimeLibcallSignatures.cpp. There’s an array declared:
545 static const char *
Fix to web assembly lib call list

Summary:
 Revision 307796 caused an internal build break in WebAssembly bots in the form of a
crash.  ex:
Here's the crash dump from one of the failing tests:

/usr/local/google/home/blaikie/dev/llvm/build/default/./bin/llc < /usr/local/google/home/blaikie/dev/llvm/src/test/CodeGen/WebAssembly/global.ll -asm-verbose=false -disable-wasm-fallthrough-return-opt -disable-wasm-explicit-locals | /usr/local/google/home/blaikie/dev/llvm/build/default/./bin/FileCheck /usr/local/google/home/blaikie/dev/llvm/src/test/CodeGen/WebAssembly/global.ll
--
Exit Code: 2

Command Output (stderr):
--
Stack dump:
0.      Program arguments: build/default/./bin/llc -asm-verbose=false -disable-wasm-fallthrough-return-opt -disable-wasm-explicit-locals
1.      Running pass 'Function Pass Manager' on module '<stdin>'.
2.      Running pass 'WebAssembly Assembly Printer' on function '@call_memcpy'
FileCheck error: '-' is empty.
FileCheck command line:  build/default/./bin/FileCheck src/test/CodeGen/WebAssembly/global.ll

The problem is in lib/Target/WebAssembly/WebAssemblyRuntimeLibcallSignatures.cpp. There’s an array declared:
static const char *
RuntimeLibcallNames[RTLIB::UNKNOWN_LIBCALL] = {

 That is defining a runtime lib call name for each entry in the enum RTLIB:Libcall from include/llvm/CodeGen/RuntimeLibcalls.h.

Revision 307796 added entries to the enum, but didn’t add entries to the RuntimeLibcallNames array, which caused a crash when attempting
to access past the end of the array.

This patch fixes the issue by adding the element atomic memmove to the WebAssembly arrays.

Reviewed by: reames

llvm-svn: 307831

Several improvements to the Fuchsia driver:

* Search for C++ library headers and libraries in directories that
are part of the toolchain distribution rather than sysroot.

* Use LLVM support utlities to construct paths to make sure the driver
is also usable on Windows for cross-compiling.

* Change the driver to inherit directly from ToolChain rather than
Generic_GCC since we don't need any of the GCC related multilib logic.

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

llvm-svn: 307830

This re-commits r307726 with valid line table relocations.

llvm-svn: 307829

Summary:
LoopRotate manually updates the DoomTree by iterating over all predecessors of a basic block and computing the Nearest Common Dominator.

When a predecessor happens to be unreachable, `DT.findNearestCommonDominator` returns nullptr.

This patch teaches LoopRotate to handle this case and fixes [[ https://bugs.llvm.org/show_bug.cgi?id=33701 | PR33701 ]].

In the future, LoopRotate should be taught to use the new incremental API for updating the DomTree.

Reviewers: dberlin, davide, uabelho, grosser

Subscribers: efriedma, mzolotukhin

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

llvm-svn: 307828

ManagedStatic<sys::Mutex> would lazilly allocate a sys::Mutex to lock
when reporting an OOM, which is a bad idea.

The three STL implementations that I know of use pthread_mutex_lock and
EnterCriticalSection to implement std::mutex. I'm pretty sure that
neither of those allocate heap memory.

It seems that we unconditionally use std::mutex without testing
LLVM_ENABLE_THREADS elsewhere in the codebase, so this should be
portable.

llvm-svn: 307827

Some libFuzzer tests on Linux would fail with bizarre error messages
unless llvm-symbolizer binary is present.

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

llvm-svn: 307826

The current code relies on the assumption that tests are included only
if LLVM_USE_SANITIZE_COVERAGE is enabled.
This commit makes it easier to relax the assumption in the future, as
the variable LIBFUZZER_FLAGS_BASE is used further in libFuzzer tests.

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

llvm-svn: 307825

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

llvm-svn: 307824

llvm-svn: 307823

If taskloop directive has no associated nogroup clause, it must emitted
inside implicit taskgroup block. Runtime supports it, but we need to
generate implicit taskgroup block explicitly to support future
reductions codegen.

llvm-svn: 307822

This is another step towards removing a combine that turns sext
into select of constants and preparing the backend for an IR
future where select is the canonical form.

Earlier commits in this area:
https://reviews.llvm.org/rL306040
https://reviews.llvm.org/rL306072
https://reviews.llvm.org/rL307404 (https://reviews.llvm.org/D34652)
https://reviews.llvm.org/rL307471

llvm-svn: 307821

We were producing bogus warnings without it.

llvm-svn: 307820

We're subtracting X from X the hard way...

llvm-svn: 307819

Summary: socket() is better to include SOCK_CLOEXEC in its type argument to avoid the file descriptor leakage.

Reviewers: chh, Eugene.Zelenko, alexfh, hokein, aaron.ballman

Reviewed By: chh, alexfh

Subscribers: srhines, mgorny, JDevlieghere, xazax.hun, cfe-commits

Tags: #clang-tools-extra

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

llvm-svn: 307818

A generic variant of IMPLICIT_DEF was added in r306875, but this
survives to selection and hits a `Cannot Select`. Add handling that
converts the note to a regular IMPLICIT_DEF.

llvm-svn: 307817

llvm-svn: 307816

llvm-svn: 307815

Summary:
Add a sequence number that identifies a ptx_kernel's parent Scop within a function to it's name to differentiate it from other kernels produced from the same function, yet different Scops.

Kernels produced from different Scops can end up having the same name. Consider a function with 2 Scops and each Scop being able to produce just one kernel. Both of these kernels have the name "kernel_0". This can lead to the wrong kernel being launched when the runtime picks a kernel from its cache based on the name alone. This patch supplements D33985, by differentiating kernels across Scops as well.

Previously (even before D33985) while profiling kernels generated through JIT e.g. Julia, [[ https://groups.google.com/d/msg/polly-dev/J1j587H3-Qw/mR-jfL16BgAJ | kernels associated with different functions, and even different SCoPs within a function, would be grouped together due to the common name ]]. This patch prevents this grouping and the kernels are reported separately.

Reviewers: grosser, bollu

Reviewed By: grosser

Subscribers: mehdi_amini, nemanjai, pollydev, kbarton

Tags: #polly

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

llvm-svn: 307814

the diagnostic to its enum value

This will be used by a script that invokes clang in a debugger and forces it
to stop when it reports a particular diagnostic.

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

llvm-svn: 307813

Summary:
Before the change:

`auto i = (Enum) 5;` => `auto i = static_cast<Enum>( 5);`

After the change:

`auto i = (Enum) 5;` => `auto i = static_cast<Enum>(5);`

Reviewers: alexfh

Reviewed By: alexfh

Subscribers: JDevlieghere, xazax.hun, cfe-commits

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

llvm-svn: 307812

As promised in D35003.

Uses -codegenprepare instead of -instcombine since we hit the same
buggy path anyway, and CGP lets us keep this test really simple
(instcombine likes turning the alloca T, N into alloca [N x T], which
hides the bug this is testing for).

llvm-svn: 307811

This test shows the problem in https://bugs.llvm.org/show_bug.cgi?id=33734

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

llvm-svn: 307810

Fix bug https://bugs.llvm.org/show_bug.cgi?id=33734

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

llvm-svn: 307809

Reviewers: slthakur, atanasyan

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

llvm-svn: 307808

I accidentally removed it in r307730.

Thanks to Martin Storsjö for noticing!

llvm-svn: 307801

`SCEV` parameter is called as `Expr` in `SCEVValidator.cpp`, as well
as in other functions in `SCEVValidator.h`.

llvm-svn: 307800

Add SDep printer to make debugging sessions more productive.

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

llvm-svn: 307799

Summary:
This follows the addition of `GetRandom` with D34412. We remove our
`/dev/urandom` code and use the new function. Additionally, change the PRNG for
a slightly faster version. One of the issues with the old code is that we have
64 full bits of randomness per "next", using only 8 of those for the Salt and
discarding the rest. So we add a cached u64 in the PRNG that can serve up to
8 u8 before having to call the "next" function again.

During some integration work, I also realized that some very early processes
(like `init`) do not benefit from `/dev/urandom` yet. So if there is no
`getrandom` syscall as well, we have to fallback to some sort of initialization
of the PRNG.

Now a few words on why XoRoShiRo and not something else. I have played a while
with various PRNGs on 32 & 64 bit platforms. Some results are below. LCG 32 & 64
are usually faster but produce respectively 15 & 31 bits of entropy, meaning
that to get a full 64-bit, you would need to call them several times. The simple
XorShift is fast, produces 32 bits but is mediocre with regard to PRNG test
suites, PCG is slower overall, and XoRoShiRo is faster than XorShift128+ and
produces full 64 bits.

%%%
root@tulip-chiphd:/data # ./randtest.arm
[+] starting xs32...
[?] xs32 duration: 22431833053ns
[+] starting lcg32...
[?] lcg32 duration: 14941402090ns
[+] starting pcg32...
[?] pcg32 duration: 44941973771ns
[+] starting xs128p...
[?] xs128p duration: 48889786981ns
[+] starting lcg64...
[?] lcg64 duration: 33831042391ns
[+] starting xos128p...
[?] xos128p duration: 44850878605ns

root@tulip-chiphd:/data # ./randtest.aarch64
[+] starting xs32...
[?] xs32 duration: 22425151678ns
[+] starting lcg32...
[?] lcg32 duration: 14954255257ns
[+] starting pcg32...
[?] pcg32 duration: 37346265726ns
[+] starting xs128p...
[?] xs128p duration: 22523807219ns
[+] starting lcg64...
[?] lcg64 duration: 26141304679ns
[+] starting xos128p...
[?] xos128p duration: 14937033215ns
%%%

Reviewers: alekseyshl

Reviewed By: alekseyshl

Subscribers: aemerson, kristof.beyls, llvm-commits

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

llvm-svn: 307798