llvm-svn: 206215

Fix cases where the Value itself is used, and not the constant value.

llvm-svn: 206214

This matches that ARM64Subtarget does for now.

This is related to <rdar://problem/16573920>

llvm-svn: 206211

Thanks to dblaikie for updating the testcase!

Debug info: (bugfix) C++ C/Dtors can be compiled to multiple functions,
therefore, their declaration cannot have one DW_AT_linkage_name.
The specific instances however can and should have that attribute.

This patch reorders the code in DwarfUnit::getOrCreateSubprogramDIE()
to emit linkage names for C/Dtors.

rdar://problem/16362674.

llvm-svn: 206210

small formatting inconsistencies with the rest of LLVM and even this
file. I looked at all the changes and they seemed like just better
formatting.

llvm-svn: 206209

In rare cases the dead definition elimination pass code can cause illegal cmn
instructions when it replaces dead registers on instructions that use
unmaterialized frame indexes. This patch disables the dead definition
optimization for instructions which include frame index operands.

rdar://16438284

llvm-svn: 206208

This patch adds a -arm64-dead-def-elimination flag so that it is possible to
disable dead definition elimination. Includes test case.

llvm-svn: 206207

llvm-svn: 206198

llvm-svn: 206197

been removed in r200442.

llvm-svn: 206196

llvm-svn: 206195

Fix a bug in which BranchProbabilityInfo wasn't setting branch weights of basic blocks inside loops correctly.

Previously, BranchProbabilityInfo::calcLoopBranchHeuristics would determine the weights of basic blocks inside loops even when it didn't have enough information to estimate the branch probabilities correctly. This patch fixes the function to exit early if it doesn't see any exit edges or back edges and let the later heuristics determine the weights.

This fixes PR18705 and <rdar://problem/15991090>.

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

llvm-svn: 206194

llvm-svn: 206193

This allows correct relocations to be generated for a symbolic
address that is being adjusted by a negative constant. Since r204294,
such expressions have triggered undefined behavior when LLVM was built
without assertions.

Credit goes to Rafael for this patch; I'm submitting it on his behalf
as he is on vacation this week.

llvm-svn: 206192

Once the auxiliary fields relating to the filename have been inspected, any
following auxiliary fields need not be visited as they have been consumed (the
following fields comprise the filepath as a single unit).

Adjust the test to catch this even if ASAN is not enabled.

llvm-svn: 206190

Summary:
This was another incorrect use of hasMips64() vs isGP64bit().

Depends on D3344

Reviewers: matheusalmeida, vmedic

Reviewed By: vmedic

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

llvm-svn: 206187

[mips] MIPS-IV is broadly the same as MIPS64 so duplicate all -mcpu=mips64 tests with -mcpu=mips4 as a starting point

Summary:
Two exceptions to this:
  test/CodeGen/Mips/octeon.ll
  test/CodeGen/Mips/octeon_popcnt.ll
these test extensions to MIPS64

One test is altered for MIPS-IV:
  test/CodeGen/Mips/mips64countleading.ll
    Tests dclo/dclz which were added in MIPS64. The MIPS-IV version tests
    that dclo/dclz are not emitted.

Four tests fail and are not in this patch:
  test/CodeGen/Mips/abicalls.ll
  test/CodeGen/Mips/fcopysign-f32-f64.ll
  test/CodeGen/Mips/fcopysign.ll
  test/CodeGen/Mips/stack-alignment.ll

Depends on D3343

Reviewers: matheusalmeida, vmedic

Reviewed By: vmedic

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

llvm-svn: 206185

Summary:
- Conditional moves acting on 64-bit GPR's should require MIPS-IV rather than MIPS64
- ISD::MUL, and ISD::MULH[US] should be lowered on all 64-bit ISA's

Patch by David Chisnall
His work was sponsored by: DARPA, AFRL

I've added additional testcases to cover as much of the codegen changes
affecting MIPS-IV as I can. Where I've been unable to find an existing
MIPS64 testcase that can be re-used for MIPS-IV (mainly tests covering
ISD::GlobalAddress and similar), I at least agree that MIPS-IV should
behave like MIPS64. Further testcases that are fixed by this patch will follow
in my next commit. The testcases from that commit that fail for MIPS-IV without
this patch are:
    LLVM :: CodeGen/Mips/2010-07-20-Switch.ll
    LLVM :: CodeGen/Mips/cmov.ll
    LLVM :: CodeGen/Mips/eh-dwarf-cfa.ll
    LLVM :: CodeGen/Mips/largeimmprinting.ll
    LLVM :: CodeGen/Mips/longbranch.ll
    LLVM :: CodeGen/Mips/mips64-f128.ll
    LLVM :: CodeGen/Mips/mips64directive.ll
    LLVM :: CodeGen/Mips/mips64ext.ll
    LLVM :: CodeGen/Mips/mips64fpldst.ll
    LLVM :: CodeGen/Mips/mips64intldst.ll
    LLVM :: CodeGen/Mips/mips64load-store-left-right.ll
    LLVM :: CodeGen/Mips/sint-fp-store_pattern.ll

Reviewers: dsanders

Reviewed By: dsanders

CC: matheusalmeida

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

llvm-svn: 206183

Patch by Nick Tomlinson!

llvm-svn: 206177

llvm-svn: 206175

Should be no other change.

llvm-svn: 206174

The 32-bit pattern is still valid: 0123 -> 3210 -> 1032.

llvm-svn: 206172

Code change is because optimizeCompareInstr didn't know how to pull the
condition code out of FCSEL instructions.

llvm-svn: 206171

AArch64 tests for this, and it's obviously a good idea. Have to invert the
condition code, of course.

llvm-svn: 206170

llvm-svn: 206169

There was one definite issue in ARM64 (the off-by-1 check for whether
a shift could be folded in) and one difference that is probably
correct: ARM64 didn't fold nodes with multiple uses into the
arithmetic operations unless optimising for code size.

llvm-svn: 206168

This transformation is only valid when being used for an EQ or NE
comparison since the flags change otherwise.

llvm-svn: 206167

llvm-svn: 206166

llvm-svn: 206164

Summary:
Previously loadImmediate() would produce MKMSK instructions with invalid
immediate values such as mkmsk r0, 9. Fix this by checking the mask size
is valid.

Reviewers: robertlytton

Reviewed By: robertlytton

CC: llvm-commits

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

llvm-svn: 206163

llvm-svn: 206154

It broke some builders, at least, i686.

llvm-svn: 206153

declaration. GCC 4.7 appears to get hopelessly confused by declaring
this function within a member function of a class template. Go figure.

llvm-svn: 206152

of '@foo'. The slash variant is prefered in LLVM and the file was
already using a mixture. =/

llvm-svn: 206151

BasicTTI::getMemoryOpCost must explicitly check for non-simple types; setting
AllowUnknown=true with TLI->getSimpleValueType is not sufficient because, for
example, non-power-of-two vector types return non-simple EVTs (not MVT::Other).

llvm-svn: 206150

abstract interface. The only user of this functionality is the JIT
memory manager and it is quite happy to have a custom type here. This
removes a virtual function call and a lot of unnecessary abstraction
from the common case where this is just a *very* thin vaneer around
a call to malloc.

Hopefully still no functionality changed here. =]

llvm-svn: 206149

declaration outside of #ifndef NDEBUG -- its used elsewhere. Sorry for
the noise.

llvm-svn: 206148

slabs rather than embedding a singly linked list in the slabs
themselves. This has a few advantages:

- Better utilization of the slab's memory by not wasting 16-bytes at the
  front.
- Simpler allocation strategy by not having a struct packed at the
  front.
- Avoids paging every allocated slab in just to traverse them for
  deallocating or dumping stats.

The latter is the really nice part. Folks have complained from time to
time bitterly that tearing down a BumpPtrAllocator, even if it doesn't
run any destructors, pages in all of the memory allocated. Now it won't.
=]

Also resolves a FIXME with the scaling of the slab sizes. The scaling
now disregards specially sized slabs for allocations larger than the
threshold.

llvm-svn: 206147

Rather than switching behaviour on whether a previous symbol has an auxiliary
symbol record for the next count of elements, simply iterate over the auxiliary
symbols right after processing the current symbol entry.  This makes the
behaviour much simpler to follow and similar to llvm-readobj and yaml2obj.

llvm-svn: 206146

If a filename is a multiple of 18 characters, there will be no null-terminator.
This will result in an invalid access by the constructed StringRef.  Add a test
case to exercise this and fix that handling.  Address this same vulnerability in
llvm-readobj as well.

llvm-svn: 206145