.clang-format's comments are removed and a (hopefully) final
set of formatting changes are applied.

Differential Revision: https://reviews.llvm.org/D38837
Differential Revision: https://reviews.llvm.org/D38920

llvm-svn: 316227

llvm-svn: 316226

r213589 was checked in as a solution to
https://bugs.llvm.org/show_bug.cgi?id=20336.

However, it is possible to use /EP with /P
to suppress #line directives AND output to
a file. There is no reason in that case to
suppress /showIncludes.

This was reported here:
https://bugs.llvm.org/show_bug.cgi?id=34997

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

llvm-svn: 316225

If there is no binary search table computed, the FDECount encoding is
DW_EH_PE_omit.  Do not attempt to read the FDECount in such a situation
as we will read an incorrect value.  binutils only writes out the
FDECount if the encoding is not DW_EH_PE_omit.

llvm-svn: 316224

This was suggested in PR35003:
https://bugs.llvm.org/show_bug.cgi?id=35003

32-bit checks may be identical to 64-bit (if we avoid those pesky scalar params!).

I'll check in the script change shortly assuming this doesn't anger any bots.

llvm-svn: 316223

To help identify shuffle combine issues

llvm-svn: 316222

llvm-svn: 316221

llvm-svn: 316220

Summary:
This change comes from using lld for i686-windows-msvc. Before this change, lld
emits an error of:

    error: relocation against symbol in discarded section: .xdata

It's possible that this could be addressed in lld, but I think this change is
reasonable on its own.

At a high level, this is being generated:

    A (.text comdat) -> B (.text) -> C (.xdata comdat)

Where A is a C++ inline function, which references B, an exception handler
thunk, which references C, the exception handling info.

With this structure, lld will error when applying relocations to B if the C it
references has been discarded (some other C has been selected).

This change checks if A is comdat, and if so places the exception registration
thunk (B) in the comdata group of A (and B).

It appears that MSVC makes the __ehhandler function comdat.

Is it possible that duplicate thunks are being emitted into the final binary
with other linkers, or are they stripping the unused thunks?

Reviewers: rnk, majnemer, compnerd, smeenai

Reviewed By: rnk, compnerd

Subscribers: llvm-commits

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

llvm-svn: 316219

Normally, if the registers holding the induction variable's bounds
are redefined inside of the loop's body, the loop cannot be converted
to a hardware loop. However, if the redefining instruction is actually
loading an immediate value into the register, this conversion is both
possible and legal (since the immediate itself will be used in the
loop setup in the preheader).

llvm-svn: 316218

We ignore the 32-bit/64-bit triple but I've tried to use i686 triples for CPUs that don't support x86_64

llvm-svn: 316217

Basic tests which are the equivalent of single-source shufflevector with variable mask.

llvm-svn: 316216

This reverts commit r314507, because the original patch is causing test
failures.

llvm-svn: 316215

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

llvm-svn: 316214

As part of tracking down machine verifier issues (PR27481)

llvm-svn: 316213

Summary:
Change clang-refactor default behavior to print the new code after refactoring
(instead of editing the source files), which would make it easier to use
and debug the refactoring action.

Reviewers: arphaman, ioeric

Reviewed By: arphaman

Subscribers: cfe-commits

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

llvm-svn: 316212

Resolves:
Fatal error: Offset not zero at the point of scalar access.
http://llvm.org/PR34992

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

llvm-svn: 316211

llvm-svn: 316210

Add a new flag, _⁠_tsan_mutex_not_static, which has the opposite sense
of _⁠_tsan_mutex_linker_init. When the new _⁠_tsan_mutex_not_static flag
is passed to _⁠_tsan_mutex_destroy, tsan ignores the destruction unless
the mutex was also created with the _⁠_tsan_mutex_not_static flag.

This is useful for constructors that otherwise woud set
_⁠_tsan_mutex_linker_init but cannot, because they are declared constexpr.

Google has a custom mutex with two constructors, a "linker initialized"
constructor that relies on zero-initialization and sets
⁠_⁠_tsan_mutex_linker_init, and a normal one which sets no tsan flags.
The "linker initialized" constructor is morally constexpr, but we can't
declare it constexpr because of the need to call into tsan as a side effect.

With this new flag, the normal c'tor can set _⁠_tsan_mutex_not_static,
the "linker initialized" constructor can rely on tsan's lazy initialization,
and _⁠_tsan_mutex_destroy can still handle both cases correctly.

Author: Greg Falcon (gfalcon)
Reviewed in: https://reviews.llvm.org/D39095

llvm-svn: 316209

(recommit #2 after checking for timeout issue). 

The original patch was an improvement to IR ValueTracking on
non-negative integers. It has been checked in to trunk (D18777,
r284022). But was disabled by default due to performance regressions.
Perf impact has improved. The patch would be enabled by default.

Reviewers: reames, hfinkel
 
Differential Revision: https://reviews.llvm.org/D34101
 
Patch by: Olga Chupina <olga.chupina@intel.com>

llvm-svn: 316208

This test checks that load from constant memory will be sunk regardless of
aliasing stores in the loop.

Patch by Daniil Suchkov!

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

llvm-svn: 316207

llvm-svn: 316205

NetBSD uses `long int` for `intptr_t` on ARM.  This was changed in SVN
r316046, referenced against other compilers.  However, NetBSD's
reference was incorrect as the current clang behaviour is more
up-to-date.  Restore the original behaviour for that target.

llvm-svn: 316204

Will re-enable once I figure out why the necessary runtime functions are
missing on some bots.

llvm-svn: 316203

Turns on EmulatedTLS support by default in EngineBuilder. ;)

llvm-svn: 316200

The commit at https://reviews.llvm.org/rL315888 is causing some failures
with internal testing. Disabling this code until we can resolve the issues.

llvm-svn: 316199

This patch breaks users using -fno-canonical-prefixes, for whom resolving
symlinks is not acceptable.

llvm-svn: 316195

GCC tries to shorten system headers in depfiles using its real path
(resolving components like ".." and following symlinks). Mimic this
feature to ensure that the Ninja build tool detects the correct
dependencies when a symlink changes directory levels, see
https://github.com/ninja-build/ninja/issues/1330

An option to disable this feature is added in case "these changed header
paths may conflict with some compilation environments", see
https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00287.html

Note that the original feature request for GCC
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52974) also included paths
preprocessed output (-E) and diagnostics. That is not implemented now
since I am not sure if it breaks something else.

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

llvm-svn: 316193

Summary:
Updated the XRayExample docs with instructions for using the llvm-xray stacks
command.

Reviewers: dberris

Subscribers: llvm-commits

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

llvm-svn: 316192

llvm-svn: 316191

[Transforms] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 316190

r316188 didn't set guessInstructionProperties=1 as it should have done.

llvm-svn: 316189

This adds the minimum necessary to support codegen for simple ALU operations
on RV32. Prolog and epilog insertion, support for memory operations etc etc 
follow in future patches.

Leave guessInstructionProperties=1 until https://reviews.llvm.org/D37065 is 
reviewed and lands.

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

llvm-svn: 316188

[Transforms] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 316187

These attributes are not supported by GCC and should not be in the gnu namespace. Switching from the GCC spelling to the GNU spelling so that they are only supported with __attribute__(()).

llvm-svn: 316186

monorepo.

llvm-svn: 316185

These attributes are supported by GCC with the gnu vendor namespace for C++11-style attributes. Enabling the gnu namespace by switching to the GCC spelling.

llvm-svn: 316184

[SelectionDAG] Add a check to getVectorShuffle to ensure that the only negative index we allow is -1.

llvm-svn: 316183

llvm-svn: 316182

Improve amdgcn macro test
Differential Revision: https://reviews.llvm.org/D38667

llvm-svn: 316181