Canonicalize all CMake booleans to 0/1 before passing them to lit, to
ensure that the Python side handles all of them consistently
and correctly. 0/1 is a safe choice of values that trigger the same
boolean interpretation in CMake, Python and C++.

Furthermore, using them without quotes improves the chance Python will
explicitly fail when an incorrect value (such as ON/OFF, TRUE/FALSE,
YES/NO) is accidentally passed, rather than silently misinterpreting
the value.

This replaces a lot of different logics spread around lit site files,
attempting to partially reproduce the boolean logic used in CMake
and usually silently failing when an uncommon value was used instead.
In fact, some of them were never working correctly since different
values were assigned in CMake and checked in Python.

The alternative solution could be to create a common parser for CMake
booleans in lit and use it consistently throughout the site files.
However, it does not seem like the best idea to create redundant
implementation of the same logic and have to follow upstream if it ever
is extended to handle more values.

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

llvm-svn: 291284

Remove config.test_examples from lit.site.cfg and the relevant
ENABLE_EXAMPLES definition from CMake. It is not used anywhere.

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

llvm-svn: 291283

We know that urem %V, C can be optimized away to %V if %V is ult C.

llvm-svn: 291282

This is fixing a bug where Loop Vectorization is widening a load but
with a lower alignment. Hoisting the load without propagating the alignment
will allow inst-combine to later deduce a higher alignment that what the pointer
actually is.

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

llvm-svn: 291281

This will make transition to SCRATCH_MEMORY easier

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

llvm-svn: 291279

Made no sense for them to be different and caused useless diffs in assembly remarks.

llvm-svn: 291274

llvm-svn: 291269

Re-apply r288561: This time with a fix where the ADDs that are part of a
3 instruction LOH would not invalidate the "LastAdrp" state. This fixes
http://llvm.org/PR31361

Previously this pass was using up to 5% compile time in some cases which
is a bit much for what it is doing. The pass featured a full blown
data-flow analysis which in the default configuration was restricted to a
single block.

This rewrites the pass under the assumption that we only ever work on a
single block. This is done in a single pass maintaining a state machine
per general purpose register to catch LOH patterns.

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

This reverts commit 9e6cedb0a4f14364d6511597a9160305e7d34493.

llvm-svn: 291266

llvm-svn: 291265

As discussed here:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/108749.html
...we should be able to better optimize this pattern.

llvm-svn: 291262

order to avoid jumpy line tables. Calls are left alone because they may be inlined.

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

llvm-svn: 291258

This usage of strcpy and snprintf was certainly safe, but using them
sets off various deprecation and lint warnings. Easier to just write the
belt and suspenders version.

llvm-svn: 291256

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

llvm-svn: 291254

Early step towards ignoring domain above a certain shuffle depth.

llvm-svn: 291248

llvm-svn: 291246

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

llvm-svn: 291245

The AVX1-only limit is never actually required in matchUnaryVectorShuffle

llvm-svn: 291244

The EVEX -> VEX fix means that AVX/AVX512 code is more likely the same now.

llvm-svn: 291242

The EVEX -> VEX fix means that AVX/AVX512 code is more likely the same now.

llvm-svn: 291241

llvm-svn: 291240

All callers of getTargetVShiftNode have access to X86Subtarget already so pass it along instead of re-extracting it.

llvm-svn: 291239

Summary: Previously we only supported constant-masked loads and stores.

Reviewers: kcc, RKSimon, pgousseau, gbedwell, vitalybuka

Subscribers: llvm-commits

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

llvm-svn: 291238

Summary:
I've noticed that these assertions don't trigger when the condition is false.
The problem is that the DEBUG(x) macro only executes x when the pass is
emitting debug output via the -debug and -debug-only=registerbankinfo command
line arguments.

Debug builds should always execute the assertions so use '#ifndef NDEBUG' instead.

Also removed an assertion that is only true the first time it's tested. <Target>RegisterBankInfo's constructor will re-use register banks causing them to be valid on subsequent tests. That
assertion will fail on the first test too in the near future.

Reviewers: t.p.northover, ab, rovka, qcolombet

Subscribers: dberris, llvm-commits, kristof.beyls

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

llvm-svn: 291235

Set the costs on the lowest target that supports the type.

llvm-svn: 291229

Added a test demonstrating bug in AVX512 division costs

llvm-svn: 291228

It is a common convention that our internal test runner depends upon.

llvm-svn: 291227

Add a --cmakedir option to llvm-config that returns the correct path to
built/installed CMake modules (i.e. lib/cmake/llvm). This is mostly
intended as a convenience option for stand-alone builds of other LLVM
projects that frequently reconstruct LLVM_CMAKE_PATH after querying
llvm-config.

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

llvm-svn: 291218

The lock needs to be acquired before the data is sent, not afterwards. This
think-o slipped in during the refactor in r286620, but went unnoticed as the
resulting bug only manifests in multi-threaded clients (of which there are none
in-tree).

No unit test as the bug depends on thread scheduling.

llvm-svn: 291216

We use PAX headers to store long filenames (>= 100 bytes).
It is not needed to emit PAX headers if filenames fit in the
Ustar header. This patch implements that optimization.

llvm-svn: 291215

llvm-svn: 291214

The ones with the bitcast need additional work to fold the mask operation properly. This will be fixed in a future commit.

llvm-svn: 291213

Utilize ConstantRange to make it easier to interpret range metadata.

llvm-svn: 291211

In LLD, we create cpio archive files for --reproduce command.
cpio was not a bad choice because it is very easy to create, but
it was sometimes hard to use because people are not familiar with
cpio command.

I noticed that creating a tar archive isn't as hard as I thought.
So I implemented it in this patch.

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

llvm-svn: 291209

This reverts commit 63165f6ae3bac1623be36d4b3ce63afa1d51a30a.

After making this change, I discovered that _Unwind_Backtrace is
unable to unwind past a signal handler after an assertion failure.
I filed a bug report about that issue in rdar://29866587 but even if
we get a fix soon, it will be awhile before it get released.

llvm-svn: 291207

Using sigaltstack on Apple platforms is a bad idea. Darwin's backtrace()
function does not work with sigaltstack, and my change in r286851 was
supposed to solve that by using _Unwind_Backtrace instead. I tested that
_Unwind_Backtrace works for crashes but then discovered that it does not
work for assertion failures when using sigaltstack, at least on macOS.
The stack trace shows only the frames on the alternate stack.
I also saw some reports of this happening for crashes, but it fails
consistently for assertion failures. I tried various things to get it to
work but the problem seems to be in _Unwind_Backtrace itself. Disabling
sigaltstack is unfortunate since it would be nice to get backtraces for
stack overflows, but at least this gets us backtraces for the more common
cases. rdar://problem/29662459

llvm-svn: 291206

This change separates how type identifiers are resolved from how intrinsic
calls are lowered. All information required to lower an intrinsic call
is stored in a new TypeIdLowering data structure. The idea is that this
data structure can either be initialized using the module itself during
regular LTO, or using the module summary in ThinLTO backends.

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

llvm-svn: 291205

llvm-svn: 291201

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

llvm-svn: 291197

We used the logBase2 of the high instead of the ceilLogBase2 resulting
in the wrong result for certain values.  For example, it resulted in an
i1 AssertZExt when the exclusive portion of the range was 3.

llvm-svn: 291196

llvm-svn: 291195