PR21202: Memory leak in Windows RWMutexImpl when using SRWLOCK

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220251 91177308-0d34-0410-b5e6-96231b3b80d8

Make AsmPrinter::EmitLabelOffsetDifference a static helper and simplify.

It had exactly one caller in a position where we know hasSetDirective is true.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220250 91177308-0d34-0410-b5e6-96231b3b80d8

[MCJIT] Temporarily revert r220245 - it broke several bots.

(See e.g. http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/17653)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220249 91177308-0d34-0410-b5e6-96231b3b80d8

Introduce enum values for previously defined metadata types. (NFC)

Our metadata scheme lazily assigns IDs to string metadata, but we have a mechanism to preassign them as well.  Using a preassigned ID is helpful since we get compile time type checking, and avoid some (minimal) string construction and comparison.  This change adds enum value for three existing metadata types:
+    MD_nontemporal = 9, // "nontemporal"
+    MD_mem_parallel_loop_access = 10, // "llvm.mem.parallel_loop_access"
+    MD_nonnull = 11 // "nonnull"

I went through an updated various uses as well.  I made no attempt to get all uses; I focused on the ones which were easily grepable and easily to translate.  For example, there were several items in LoopInfo.cpp I chose not to update.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220248 91177308-0d34-0410-b5e6-96231b3b80d8

Extend the verifier to validate range metadata on calls and invokes.

Range metadata applies to loads, call, and invokes.  We were validating that metadata applied to loads was correct according to the LangRef, but we were not validating metadata applied to calls or invokes.  This change extracts the checking functionality to a common location, reuses it for all valid locations, and adds a simple test to ensure a misused range on a call gets reported.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220246 91177308-0d34-0410-b5e6-96231b3b80d8

[MCJIT] Make MCJIT honor symbol visibility settings when populating the global
symbol table.

Patch by Anthony Pesch. Thanks Anthony!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220245 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Fix a bug in the lowering of the mask of VSELECT.
X86 code to lower VSELECT messed a bit with the bits set in the mask of VSELECT
when it knows it can be lowered into BLEND. Indeed, only the high bits need to be
set for those and it optimizes those accordingly.
However, when the mask is a compile time constant, the lowering will be handled
by the generic optimizer and those modifications will generate bad code in the
generic optimizer.

This patch fixes that by preventing the optimization if the VSELECT will be
handled by the generic optimizer.

<rdar://problem/18675020>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220242 91177308-0d34-0410-b5e6-96231b3b80d8

Introduce a 'nonnull' metadata on Load instructions.

The newly introduced 'nonnull' metadata is analogous to existing 'nonnull' attributes, but applies to load instructions rather than call arguments or returns.  Long term, it would be nice to combine these into a single construct.   The value of the load is allowed to vary between successive loads, but null is not a valid value to be loaded by any load marked nonnull.

Reviewed by: Hal Finkel
Differential Revision:  http://reviews.llvm.org/D5220

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220240 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Memory folding for commutative instructions (updated)

This patch improves support for commutative instructions in the x86 memory folding implementation by attempting to fold a commuted version of the instruction if the original folding fails - if that folding fails as well the instruction is 're-commuted' back to its original order before returning.

Updated version of r219584 (reverted in r219595) - the commutation attempt now explicitly ensures that neither of the commuted source operands are tied to the destination operand / register, which was the source of all the regressions that occurred with the original patch attempt.

Added additional regression test case provided by Joerg Sonnenberger.

Differential Revision: http://reviews.llvm.org/D5818

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220239 91177308-0d34-0410-b5e6-96231b3b80d8

Explain why we don't always use --gc-sections.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220237 91177308-0d34-0410-b5e6-96231b3b80d8

ARM: rework Thumb1 frame index rewriting

The previous code had a few problems, motivating the choices here.

1. It could create instructions clobbering CPSR, but the incoming MachineInstr
   didn't reflect this. A potential source of corruption. This is why the patch
   has a new PseudoInst for before lowering.
2. Similarly, there was some code to handle the incoming instruction not being
   ARMCC::AL, but this would have caused massive problems if it was actually
   invoked when a complex offset needing more than one instruction was requested.
3. It wasn't designed to handle unaligned pointers (or offsets). These should
   probably be minimised anyway, but the code needs to deal with them properly
   regardless.
4. It had some rather dubious ad-hoc code to avoid calling
   emitThumbRegPlusImmediate, a function which should be designed to do precisely
   this job.

We seem to cover the common cases correctly now, and hopefully can enhance
emitThumbRegPlusImmediate to handle any extra optimisations we need to add in
future.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220236 91177308-0d34-0410-b5e6-96231b3b80d8

Try to fix GCC error about invalid use of const_cast in const version of ErrorOr::get()

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220233 91177308-0d34-0410-b5e6-96231b3b80d8

Constify getELFDynamicSymbolIterators standalone function. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220232 91177308-0d34-0410-b5e6-96231b3b80d8

Add const version of OwningBinary::getBinary

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220231 91177308-0d34-0410-b5e6-96231b3b80d8

Be more specific about return type of MachOUniversalBinary::getObjectForArch

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220230 91177308-0d34-0410-b5e6-96231b3b80d8

Constify input argument of RelocVisitor and DWARFContext constructors. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220228 91177308-0d34-0410-b5e6-96231b3b80d8

Teach Lit to catch OSError exceptions when creating a process during the
execution of a shell command. This can happen for example if the
``RUN:`` line calls a python script which can work correctly under
Linux/OSX but will not work under Windows. A more useful error message
is now shown rather than an unhelpful backtrace.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220227 91177308-0d34-0410-b5e6-96231b3b80d8

Moved out IIT_V64 from common values section.
Thanks Juergen Ributzka for notice.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220224 91177308-0d34-0410-b5e6-96231b3b80d8

[AArch64] test case for compfail fixed by r219748

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220206 91177308-0d34-0410-b5e6-96231b3b80d8

Fix Intrinsic::getType not working with vararg

VarArg Intrinsic functions are encoded with "void" type as the last
argument. Now Intrinsic::getType can correctly return all the intrinsic
function type.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220205 91177308-0d34-0410-b5e6-96231b3b80d8

[Thumb2] RFE, SRS and "SUBS pc, lr" are undefined on v7M

These instructions are related to the v7[AR] exception model, and are
not defined on v7M.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220204 91177308-0d34-0410-b5e6-96231b3b80d8

Remove unnecessary else.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220200 91177308-0d34-0410-b5e6-96231b3b80d8

Revert r220174, "Always use -Wl,-gc-sections on our build."

It dropped required functions for plugins with gnu ld 2.20 and 2.21.

  Failing Tests (1):
      LLVM :: Feature/load_module.ll

  Hello: bin/opt: symbol lookup error: lib/LLVMHello.so: undefined symbol: _ZN4llvm11raw_ostream13write_escapedENS_9StringRefEb

  Failing Tests (1):
      Clang :: Frontend/plugins.c

  error: unable to load plugin 'lib/PrintFunctionNames.so': 'lib/PrintFunctionNames.so: undefined symbol: _ZN5clang15PluginASTAction6anchorEv'

I think we should inspect linker's version or behavior to introduce --gc-sections for --export-dynamic.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220198 91177308-0d34-0410-b5e6-96231b3b80d8

[ARM] Do not select SMULW[BT] or SMLAW[BT]

The current instruction selection patterns for SMULW[BT] and SMLAW[BT]
are incorrect. These instructions multiply a 32-bit and a 16-bit value
(both signed) and return the top 32 bits of the 48-bit result. This
preserves the 16 bits of overflow, whereas the patterns they currently
match truncate the result to 16 bits then sign extend.

To select these instructions, we would need to match an ISD::SMUL_LOHI,
a sign extend, two shifts and an or. There is no way to match SMUL_LOHI
in an instruction pattern as it defines multiple values, so this would
have to be done in C++. I have raised
http://llvm.org/bugs/show_bug.cgi?id=21297 to cover allowing correct
selection of these instructions.

This fixes http://llvm.org/bugs/show_bug.cgi?id=19396

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220196 91177308-0d34-0410-b5e6-96231b3b80d8

[Thumb] Fix crash in Thumb1RegisterInfo::rewriteFrameIndex

This function can, for some offsets from the SP, split one instruction
into two. Since it re-uses the original instruction as the first
instruction of the result, we need ensure its result register is not
marked as dead before we use it in the second instruction.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220194 91177308-0d34-0410-b5e6-96231b3b80d8

Switch the default DataLayout to be little endian, and make the variable
be BigEndian so the default can continue to be zero-initialized.

This is one of the prerequisites to making DataLayout a constant and
always available part of every module.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220193 91177308-0d34-0410-b5e6-96231b3b80d8

Remove some completely superfluous trailing comments and clang-format
this header to remove numerous formatting inconsistencies that impede
making simple changes here without large diffs.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220192 91177308-0d34-0410-b5e6-96231b3b80d8

Clean up the comments and doxygen for DataLayout.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220191 91177308-0d34-0410-b5e6-96231b3b80d8

Fix a miscompile introduced in r220178.

The original code had an implicit assumption that if the test for
allocas or globals was reached, the two pointers were not equal. With my
changes to make the pointer analysis more powerful here, I also had to
guard against circumstances where the results weren't useful. That in
turn violated the assumption and gave rise to a circumstance in which we
could have a store with both the queried pointer and stored pointer
rooted at *the same* alloca. Clearly, we cannot ignore such a store.
There are other things we might do in this code to better handle the
case of both pointers ending up at the same alloca or global, but it
seems best to at least make the test explicit in what it intends to
check.

I've added tests for both the alloca and global case here.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220190 91177308-0d34-0410-b5e6-96231b3b80d8

IR: Replace DataLayout::RoundUpAlignment with RoundUpToAlignment

No functional change intended, just cleaning up some code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220187 91177308-0d34-0410-b5e6-96231b3b80d8

Fix a somewhat subtle pair of issues with JumpThreading I introduced in
r220178. First, the creation routine doesn't insert prior to the
terminator of the basic block provided, but really at the end of the
basic block. Instead, get the terminator and insert before that. The
next issue was that we need to ensure multiple PHI node entries for
a single predecessor re-use the same cast instruction rather than
creating new ones.

All of the logic here was without tests previously. I've reduced and
added a test case from the test suite that crashed without both of these
fixes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220186 91177308-0d34-0410-b5e6-96231b3b80d8

[PBQP] Use DenseSet rather than std::set for PBQP's PoolCostAllocator
implementation.

This is good for a ~6% reduction in total compile time on the nightly test suite
when running with -regalloc=pbqp.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220183 91177308-0d34-0410-b5e6-96231b3b80d8

Teach the load analysis driving core instcombine logic and other bits of
logic to look through pointer casts, making them trivially stronger in
the face of loads and stores with intervening pointer casts.

I've included a few test cases that demonstrate the kind of folding
instcombine can do without pointer casts and then variations which
obfuscate the logic through bitcasts. Without this patch, the variations
all fail to optimize fully.

This is more important now than it has been in the past as I've started
moving the load canonicialization to more closely follow the value type
requirements rather than the pointer type requirements and thus this
needs to be prepared for more pointer casts. When I made the same change
to stores several test cases regressed without logic along these lines
so I wanted to systematically improve matters first.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220178 91177308-0d34-0410-b5e6-96231b3b80d8

Add a datalayout string to this test so that it exercises the full gamut
of InstCombine rather than just the bits enabled when datalayout is
optional.

The primary fixes here are because now things are little endian.

In good news, silliness like this seems like it will be going away as
we've got pretty stong consensus on dropping optional datalayout
entirely.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220176 91177308-0d34-0410-b5e6-96231b3b80d8

Always use -Wl,-gc-sections on our build.

Both bfd ld and gold correctly handle --export-dynamic, so gc-sections is safe even for binaries
that support plugins.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220174 91177308-0d34-0410-b5e6-96231b3b80d8

[PowerPC] Clean up -mattr=+vsx tests to always specify -mcpu

We recently discovered an issue that reinforces what a good idea it is
to always specify -mcpu in our code generation tests, particularly for
-mattr=+vsx.  This patch ensures that all tests that specify
-mattr=+vsx also specify -mcpu=pwr7 or -mcpu=pwr8, as appropriate.

Some of the uses of -mattr=+vsx added recently don't make much sense
(when specified for -mtriple=powerpc-apple-darwin8 or -march=ppc32,
for example).  For cases like this I've just removed the extra VSX
test commands; there's enough coverage without them.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220173 91177308-0d34-0410-b5e6-96231b3b80d8

[PowerPC] Temporarily disable VSX for PowerPC fast-isel tests

Patch by Bill Seurer; some comment formatting changes by me.

There are a few PowerPC test cases for FastISel support that currently
fail with VSX support enabled.  The temporary workaround under
discussion in http://reviews.llvm.org/D5362 helps, but the tests still
fail because they specify -fast-isel-abort, and the VSX workaround
punts back to SelectionDAG.  We have plans to fix FastISel permanently
for VSX, but until that's in place these tests are preventing us from
enabling VSX by default.  Therefore we are adding -mattr=-vsx to these
tests until the full support is ready.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220172 91177308-0d34-0410-b5e6-96231b3b80d8

[PowerPC] Re-enable VSX test line for fma.ll with -mcpu=pwr7

The VSX testing variant in test/CodeGen/PowerPC/fma.ll had to be
disabled because of unexpected behavior on many of the builders.  I
tracked this down to a situation that occurs when the VSX attribute is
enabled for a target that disables the MI early scheduling pass.  This
patch adds -mcpu=pwr7 to make this predictable.  The other issue will
be addressed separately.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220171 91177308-0d34-0410-b5e6-96231b3b80d8

[ADT] Add a 'find_as' operation to DenseSet.

This operation is analogous to its counterpart in DenseMap: It allows lookup
via cheap-to-construct keys (provided that getHashValue and isEqual are
implemented for the cheap key-type in the DenseMapInfo specialization).

Thanks to Chandler for the review.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220168 91177308-0d34-0410-b5e6-96231b3b80d8

Do a better and more complete job of preserving metadata when combining
loads.

This handles many more cases than just the AA metadata, some of them
suggested by Hal in his review of the AA metadata handling patch. I've
tried to test this behavior where tractable to do so.

I'll point out that I have specifically *not* included a test for
debuginfo because it was going to require 2 or 3 times as much work to
craft some input which would survive the "helpful" stripping of debug
info metadata that doesn't match the desired schema. This is another
good example of why the current state of write-ability for our debug
info metadata is unacceptable. I spent over 30 minutes trying to conjure
some test case that would survive, even copying from other debug info
tests, but it always failed to survive with no explanation of why or how
I might fix it. =[

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220165 91177308-0d34-0410-b5e6-96231b3b80d8

Move previously dead code to handle computing the known bits of an alias
up to where it actually works as intended. The problem is that
a GlobalAlias isa GlobalValue and so the prior block handled all of the
cases.

This allows us to constant fold based on the actual constant expression
in the global alias. As an example, see the last function in the newly
added test case which explicitly aligns an unaligned pointer using
constant expression math. Without this change, we fail to see that and
fold an alignment test to zero.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220164 91177308-0d34-0410-b5e6-96231b3b80d8

InstCombine: (sub (or A B) (xor A B)) --> (and A B)

The following implements the transformation:
(sub (or A B) (xor A B)) --> (and A B).

Patch by Ankur Garg!

Differential Revision: http://reviews.llvm.org/D5719

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220163 91177308-0d34-0410-b5e6-96231b3b80d8

InstCombine: Optimize icmp eq/ne (shl Const2, A), Const1

The following implements the optimization for sequences of the form:
icmp eq/ne (shl Const2, A), Const1

Such sequences can be transformed to:
icmp eq/ne A, (TrailingZeros(Const1) - TrailingZeros(Const2))

This handles only the equality operators for now. Other operators need
to be handled.

Patch by Ankur Garg!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220162 91177308-0d34-0410-b5e6-96231b3b80d8

Fix a long-standing miscompile in the load analysis that was uncovered
by my refactoring of this code.

The method isSafeToLoadUnconditionally assumes that the load will
proceed with the preferred type alignment. Given that, it has to ensure
that the alloca or global is at least that aligned. It has always done
this historically when a datalayout is present, but has never checked it
when the datalayout is absent. When I refactored the code in r220156,
I exposed this path when datalayout was present and that turned the
latent bug into a patent bug.

This fixes the issue by just removing the special case which allows
folding things without datalayout. This isn't worth the complexity of
trying to tease apart when it is or isn't safe without actually knowing
the preferred alignment.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220161 91177308-0d34-0410-b5e6-96231b3b80d8

Switch how the datalayout availability test is handled in this code to
make much more sense and in theory be more correct.

If you trace the code alllll the way back to when it was first
introduced, the comments make it slightly more clear what was going on
here. At that time, the only way Base != V was if DL (then TD) was
non-null. As a consequence, if DL *was* null, that meant we were loading
directly from the alloca or global found above the test. After
refactoring, this has become at least terribly subtle and potentially
incorrect. There are many forms of pointer manipulation that can be
traversed without DataLayout, and some of them would in fact change the
size of object being loaded vs. allocated.

Rather than this subtlety, I've hoisted the actual 'return true' bits
into the code which actually found an alloca or global and based them on
the loaded pointer being that alloca or global. This is both more clear
and safer. I've also added comments about exactly why this set of
predicates is used.

I've also corrected a misleading comment about globals -- if overridden
they may not just have a different size, they may be null and completely
unsafe to load from!

Hopefully this confuses the next reader a bit less. I don't have any
test cases or anything, the patch is motivated strictly to improve the
readability of the code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220156 91177308-0d34-0410-b5e6-96231b3b80d8

Use triple predicate functions instead of checking values directly. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220155 91177308-0d34-0410-b5e6-96231b3b80d8

Rename 'TD' to 'DL' in this function as the argument is now a DataLayout
argument.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220151 91177308-0d34-0410-b5e6-96231b3b80d8

Fix the other comment to use modern doxygen style and be a bit more
direct. Notably, comment on the fact that the loaded type is significant
in that it determines how wide of an access must be safe.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220150 91177308-0d34-0410-b5e6-96231b3b80d8

More formatting cleanup brought to you by clang-format.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220149 91177308-0d34-0410-b5e6-96231b3b80d8

Clean up doxygen syntax and reword comments to flow better, have a brief
section, and not have unfinished sentence fragments.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220147 91177308-0d34-0410-b5e6-96231b3b80d8

Clean up the formatting and trailing whitespace of a routine before
editting it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220146 91177308-0d34-0410-b5e6-96231b3b80d8

[PBQP] Move register-allocation specific PBQP code into RegAllocPBQP.h.

Just clean-up - no functional change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220145 91177308-0d34-0410-b5e6-96231b3b80d8

[PBQP] Replace the interference-constraints algorithm with a faster version
loosely based on linear scan.

On x86-64 this is good for a ~2% drop in compile time on the nightly test suite.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220143 91177308-0d34-0410-b5e6-96231b3b80d8

Preserve AA metadata when combining (cast (load (...))) -> (load (cast
(...))).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220141 91177308-0d34-0410-b5e6-96231b3b80d8

[InstCombine] Do an about-face on how LLVM canonicalizes (cast (load
...)) and (load (cast ...)): canonicalize toward the former.

Historically, we've tried to load using the type of the *pointer*, and
tried to match that type as closely as possible removing as many pointer
casts as we could and trading them for bitcasts of the loaded value.
This is deeply and fundamentally wrong.

Repeat after me: memory does not have a type! This was a hard lesson for
me to learn working on SROA.

There is only one thing that should actually drive the type used for
a pointer, and that is the type which we need to use to load from that
pointer. Matching up pointer types to the loaded value types is very
useful because it minimizes the physical size of the IR required for
no-op casts. Similarly, the only thing that should drive the type used
for a loaded value is *how that value is used*! Again, this minimizes
casts. And in fact, the *only* thing motivating types in any part of
LLVM's IR are the types used by the operations in the IR. We should
match them as closely as possible.

I've ended up removing some tests here as they were testing bugs or
behavior that is no longer present. Mostly though, this is just cleanup
to let the tests continue to function as intended.

The only fallout I've found so far from this change was SROA and I have
fixed it to not be impeded by the different type of load. If you find
more places where this change causes optimizations not to fire, those
too are likely bugs where we are assuming that the type of pointers is
"significant" for optimization purposes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220138 91177308-0d34-0410-b5e6-96231b3b80d8

Remove a test that was ported from the old llvm-gcc frontend test suite.

This test is pretty awesome. It is claiming to test devirtualization.
However, the code in question is not in fact devirtualized by LLVM. If
you take the original C++ test case and run it through Clang at -O3 we
fail to devirtualize it completely. It also isn't a sufficiently focused
test case.

The *reason* we fail to devirtualize it isn't because of any missing
instcombine though. Instead, it is because we fail to emit an available
externally vtable and thus the vtable is just an external and completely
opaque. If I cause the vtable to be emitted, we successfully
devirtualize things.

Anyways, I'm just removing it because it is providing negative value at
this point: it isn't representative of the output of Clang really, LLVM
isn't doing the transform it claims to be testing, LLVM's failure to do
the transform isn't actually an LLVM bug at all and we shouldn't be
testing for it here, and finally the test is written in such a way that
it will trivially pass even when the point of the test is failing.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220137 91177308-0d34-0410-b5e6-96231b3b80d8

[llvm-objdump] don't test timestamp dump as that is time zone dependent

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220123 91177308-0d34-0410-b5e6-96231b3b80d8

[llvm-objdump] enhance test case for mach-o -private-headers

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220120 91177308-0d34-0410-b5e6-96231b3b80d8

[llvm-objdump] Fix mach-o binding decompression error

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220119 91177308-0d34-0410-b5e6-96231b3b80d8

[SROA] Change how SROA does vector-based promotion of allocas to handle
cases where the alloca type, the load types, and the store types used
all disagree.

Previously, the only way that vector-based promotion occured was if the
alloca type was a vector type. This was one of the *very* few remaining
uses of the alloca's type to guide SROA/mem2reg left in LLVM. It turns
out it was a bad idea.

The alloca type can change very easily based on the mixture of types
loaded and stored to that alloca. We shouldn't be relying on it as
a signal for very much. Instead, the source of truth should be loads and
stores. We should canonicalize the loads and stores as much as possible
and then rely on them exclusively in SROA.

When looking and loads and stores, we may find many different candidate
vector types. This change will let SROA try all of them to find a vector
type which is a viable way to promote the entire alloca to a vector
register.

With this change, it becomes possible to do better canonicalization and
optimization of loads and stores without breaking SROA in random ways,
and that should allow fixing a core source of performance loss in hot
numerical loops such as those in Eigen.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220116 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Add global atomicrmw xchg

v2: Add separate offset/no-offset tests

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <matthew.arsenault@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220110 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Add global atomicrmw xor

v2: Add separate offset/no-offset tests

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <matthew.arsenault@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220109 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Add global atomicrmw or

v2: Add separate offset/no-offset tests

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <matthew.arsenault@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220108 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Add global atomicrmw min/umin

v2: Add separate offset/no-offset tests

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <matthew.arsenault@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220107 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Add global atomicrmw max/umax

v2: Add separate offset/no-offset tests

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <matthew.arsenault@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220106 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Add global atomicrmw and

v2: Add separate offset/no-offset tests

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <matthew.arsenault@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220105 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Add global atomicrmw sub

v2: Add separate offset/no-offset tests

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <matthew.arsenault@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220104 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Fix/add tests for atomicrmw add

The previous tests claimed to test constant offsets in the function name,
but the tests weren't actually testing them.

Clone the tests, and do testing of all combinations of the following:
1) with/without constant pointer offset
2) 32/64-bit addressing modes
3) Usage and non-usage of the return value from the atomicrmw

Reviewed-by: Matt Arsenault <matthew.arsenault@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220103 91177308-0d34-0410-b5e6-96231b3b80d8

R600: Rename atomic_load global tests to atomic_add

The function name now matches what it's actually testing.

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <matthew.arsenault@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220102 91177308-0d34-0410-b5e6-96231b3b80d8

[msan] Fix handling of byval arguments with large alignment.

MSan param-tls slots are 8-byte aligned. This change clips
alignment of memcpy into param-tls to 8.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220101 91177308-0d34-0410-b5e6-96231b3b80d8

Check for dynamic alloca's when selecting lifetime intrinsics.

TL;DR: Indexing maps with [] creates missing entries.

The long version:

When selecting lifetime intrinsics, we index the *static* alloca map with the AllocaInst we find for that lifetime.  Trouble is, we don't first check to see if this is a dynamic alloca.

On the attached example, this causes a dynamic alloca to create an entry in the static map, and returns 0 (the default) as the frame index for that lifetime.  0 was used for the frame index of the stack protector, which given that it now has a lifetime, is coloured, and merged with other stack slots.

PEI would later trigger an assert because it expects the stack protector to not be dead.

This fix ensures that we only get frame indices for static allocas, ie, those in the map.  Dynamic ones are effectively dropped, which is suboptimal, but at least isn't completely broken.

rdar://problem/18672951

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220099 91177308-0d34-0410-b5e6-96231b3b80d8

[PowerPC] Disable +vsx RUN line for fma.ll due to inconsistency on other builders

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220094 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "TRE: make TRE a bit more aggressive"

This reverts commit r219899.

This also updates byval-tail-call.ll to make it clear what was breaking.
Adding r219899 again will cause the load/store to disappear.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220093 91177308-0d34-0410-b5e6-96231b3b80d8

[PowerPC] Change assert to better form

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220092 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Remove redundant setting of instruction bits

These are all set on the instruction base classes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220091 91177308-0d34-0410-b5e6-96231b3b80d8

[PowerPC] Change liveness testing in VSX FMA mutation pass

With VSX enabled, LLVM crashes when compiling
test/CodeGen/PowerPC/fma.ll.  I traced this to the liveness test
that's revised in this patch. The interval test is designed to only
work for virtual registers, but in this case the AddendSrcReg is
physical. Since there is already a walk of the MIs between the
AddendMI and the FMA, I added a check for def/kill of the AddendSrcReg
in that loop.  At Hal Finkel's request, I converted the liveness test
to an assert restricted to virtual registers.

I've changed the fma.ll test to have VSX and non-VSX variants so we
can test both kinds of multiply-adds.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220090 91177308-0d34-0410-b5e6-96231b3b80d8

Disable ccache for go tests.

Should fix llvm-clang-lld-x86_64-debian-fast bot.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220071 91177308-0d34-0410-b5e6-96231b3b80d8

Fix typo

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220068 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Also check for FPImm literal constants

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220067 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Allow commuting with source modifiers

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220066 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Simplify code with hasModifiersSet

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220065 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Fix general commuting breaking src mods

The generic code trying to use findCommutedOpIndices won't
understand that it needs to swap the modifier operands also,
so it should fail if they are set.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220064 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Cleanup code with ChangeToFPImmediate

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220063 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Allow comuting fp immediates

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220062 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Use early return instead of checking condition twice

Any commutable instruction will have at least src1.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220061 91177308-0d34-0410-b5e6-96231b3b80d8

We also need to catch OSError here.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220058 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Use complex pattern for MUBUF load patterns.

This eliminates a use of the SI_ADDR64_RSRC pseudo

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220057 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Remove SI_BUFFER_RSRC pseudo

Just use REG_SEQUENCE directly, so there are fewer
instructions to need to deal with later.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220056 91177308-0d34-0410-b5e6-96231b3b80d8

[Stackmaps] Enable invoking the patchpoint intrinsic.

Patch by Kevin Modzelewski
Reviewers: atrick, ributzka
Reviewed By: ributzka
Subscribers: llvm-commits, reames

Differential Revision: http://reviews.llvm.org/D5634

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220055 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Fix missed selection of non-temporal store of zero vector.

When the input to a store instruction was a zero vector, the backend
always selected a normal vector store regardless of the non-temporal
hint. This is fixed by this patch.

This fixes PR19370.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220054 91177308-0d34-0410-b5e6-96231b3b80d8

[AArch64] Fix a silent codegen fault in BUILD_VECTOR lowering.

We should be talking about the number of source elements, not the number of destination elements, given we know at this point that the source and dest element numbers are not the same.

While we're at it, avoid writing to std::vector::end()...

Bug found with random testing and a lot of coffee.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220051 91177308-0d34-0410-b5e6-96231b3b80d8

Don't crash if find_executable return None.

This was crashing when trying to run the tests on Windows.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220048 91177308-0d34-0410-b5e6-96231b3b80d8

[PowerPC] Enable use of lxvw4x/stxvw4x in VSX code generation

Currently the VSX support enables use of lxvd2x and stxvd2x for 2x64
types, but does not yet use lxvw4x and stxvw4x for 4x32 types.  This
patch adds that support.

As with lxvd2x/stxvd2x, this involves straightforward overriding of
the patterns normally recognized for lvx/stvx, with preference given
to the VSX patterns when VSX is enabled.

In addition, the logic for permitting misaligned memory accesses is
modified so that v4r32 and v4i32 are treated the same as v2f64 and
v2i64 when VSX is enabled.  Finally, the DAG generation for unaligned
loads is changed to just use a normal LOAD (which will become lxvw4x)
on P8 and later hardware, where unaligned loads are preferred over
lvsl/lvx/lvx/vperm.

A number of tests now generate the VSX loads/stores instead of
lvx/stvx, so this patch adds VSX variants to those tests.  I've also
added <4 x float> tests to the vsx.ll test case, and created a
vsx-p8.ll test case to be used for testing code generation for the
P8Vector feature.  For now, that simply tests the unaligned load/store
behavior.

This has been tested along with a temporary patch to enable the VSX
and P8Vector features, with no new regressions encountered with or
without the temporary patch applied.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220047 91177308-0d34-0410-b5e6-96231b3b80d8

Mips: Only set divrem i64 to custom on 64bit

Reviewed-by: Daniel Sanders <daniel.sanders@imgtec.com>
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220046 91177308-0d34-0410-b5e6-96231b3b80d8

R600: Add EG to FMA test

Reviewed-by: Tom Stellard <tom@stellard.net>
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220045 91177308-0d34-0410-b5e6-96231b3b80d8

SelectionDAG: Add sext_inreg optimizations

v2: use dyn_cast
    fixup comments
v3: use cast

Reviewed-by: Matt Arsenault <arsenm2@gmail.com>
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220044 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Add support for COP1's Branch-On-Cond-Likely instructions

Summary: Depends on D5782

Reviewers: dsanders

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D5802

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220042 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Add support for COP0's Branch-On-Cond-Likely instructions

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D5782

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220036 91177308-0d34-0410-b5e6-96231b3b80d8

[DSE] Remove no-data-layout-only type-based overlap checking

DSE's overlap checking contained special logic, used only when no DataLayout
was available, which inferred a complete overwrite when the pointee types were
equal. This logic seems fine for regular loads/stores, but does not work for
memcpy and friends. Instead of fixing this, I'm just removing it.
Philosophically, transformations should not contain enhanced behavior used only
when data layout is lacking (data layout should be strictly additive), and
maintaining these rarely-tested code paths seems not worthwhile at this stage.

Credit to Aliaksei Zasenka for the bug report and the diagnosis. The test case
(slightly reduced from that provided by Aliaksei) replaces the original
contents of test/Transforms/DeadStoreElimination/no-targetdata.ll -- a few
other tests have been updated to have a data layout.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220035 91177308-0d34-0410-b5e6-96231b3b80d8

Fix bashism in build.sh.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220027 91177308-0d34-0410-b5e6-96231b3b80d8