Implement LowerReturn_64 for SPARC v9.

Integer return values are sign or zero extended by the callee, and
structs up to 32 bytes in size can be returned in registers.

The CC_Sparc64 CallingConv definition is shared between
LowerFormalArguments_64 and LowerReturn_64. Function arguments and
return values are passed in the same registers.

The inreg flag is also used for return values. This is required to handle
C functions returning structs containing floats and ints:

  struct ifp {
    int i;
    float f;
  };

  struct ifp f(void);

LLVM IR:

  define inreg { i32, float } @f() {
     ...
     ret { i32, float } %retval
  }

The ABI requires that %retval.i is returned in the high bits of %i0
while %retval.f goes in %f1.

Without the inreg return value attribute, %retval.i would go in %i0 and
%retval.f would go in %f3 which is a more efficient way of returning
%multiple values, but it is not ABI compliant for returning C structs.

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

SPARC v9 stack pointer bias.

64-bit SPARC v9 processes use biased stack and frame pointers, so the
current function's stack frame is located at %sp+BIAS .. %fp+BIAS where
BIAS = 2047.

This makes more local variables directly accessible via [%fp+simm13]
addressing.

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

Implement PPCInstrInfo::FoldImmediate

There are certain PPC instructions into which we can fold a zero immediate
operand. We can detect such cases by looking at the register class required
by the using operand (so long as it is not otherwise constrained).

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

PPC ISEL is a select and never has side effects

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

Add a comment to TargetInstrInfo about FoldImmediate

This comment documents the current behavior of the ARM implementation of this
callback, and also the soon-to-be-committed PPC version.

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

Complete formal arguments for the SPARC v9 64-bit ABI.

All arguments are formally assigned to stack positions and then promoted
to floating point and integer registers. Since there are more floating
point registers than integer registers, this can cause situations where
floating point arguments are assigned to registers after integer
arguments that where assigned to the stack.

Use the inreg flag to indicate 32-bit fragments of structs containing
both float and int members.

The three-way shadowing between stack, integer, and floating point
registers requires custom argument lowering. The good news is that
return values are passed in the exact same way, and we can share the
code.

Still missing:

 - Update LowerReturn to handle structs returned in registers.
 - LowerCall.
 - Variadic functions.

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

typo

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

Remove last use of InMemoryStruct from MachOObjectFile.cpp.

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

Don't use InMemoryStruct<macho::SymtabLoadCommand>.

This also required not using the RegisterStringTable API, which is also a
good thing.

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

Don't use InMemoryStruct in getSymbol64TableEntry.

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

Don't use InMemoryStruct in getSymbolTableEntry.

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

Don't use InMemoryStruct in getRelocation.

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

Dwarf: use utostr on CUID to append to SmallString.

We used to do "SmallString += CUID", which is incorrect, since CUID will
be truncated to a char.

rdar://problem/13573833

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

Removed trailing whitespace.

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

R600/SI: Add support for buffer stores v2

v2:
  - Use the ADDR64 bit

Reviewed-by: Christian König <christian.koenig@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178931 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Use same names for corresponding MUBUF operands and encoding fields

The code emitter knows how to encode operands whose name matches one of
the encoding fields.  If there is no match, the code emitter relies on
the order of the operand and field definitions to determine how operands
should be encoding.  Matching by order makes it easy to accidentally break
the instruction encodings, so we prefer to match by name.

Reviewed-by: Christian König <christian.koenig@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178930 91177308-0d34-0410-b5e6-96231b3b80d8

R600: Add RV670 processor

This is an R600 GPU with double support.

Reviewed-by: Christian König <christian.koenig@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178929 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Add processor types for each SI variant

Reviewed-by: Christian König <christian.koenig@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178928 91177308-0d34-0410-b5e6-96231b3b80d8

R600/SI: Avoid generating S_MOVs with 64-bit immediates v2

SITargetLowering::analyzeImmediate() was converting the 64-bit values
to 32-bit and then checking if they were an inline immediate.  Some
of these conversions caused this check to succeed and produced
S_MOV instructions with 64-bit immediates, which are illegal.

v2:
  - Clean up logic

Reviewed-by: Christian König <christian.koenig@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178927 91177308-0d34-0410-b5e6-96231b3b80d8

Enable early if conversion on PPC

On cores for which we know the misprediction penalty, and we have
the isel instruction, we can profitably perform early if conversion.
This enables us to replace some small branch sequences with selects
and avoid the potential stalls from mispredicting the branches.

Enabling this feature required implementing canInsertSelect and
insertSelect in PPCInstrInfo; isel code in PPCISelLowering was
refactored to use these functions as well.

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

Correct the PPC A2 misprediction penalty

The manual states that there is a minimum of 13 cycles from when the
mispredicted branch is issued to when the correct branch target is
issued.

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

An objc_retain can serve as a use for a different pointer.

This is the counterpart to commit r160637, except it performs the action
in the bottomup portion of the data flow analysis.

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

Properly model precise lifetime when given an incomplete dataflow sequence.

The normal dataflow sequence in the ARC optimizer consists of the following
states:

    Retain -> CanRelease -> Use -> Release

The optimizer before this patch stored the uses that determine the lifetime of
the retainable object pointer when it bottom up hits a retain or when top down
it hits a release. This is correct for an imprecise lifetime scenario since what
we are trying to do is remove retains/releases while making sure that no
``CanRelease'' (which is usually a call) deallocates the given pointer before we
get to the ``Use'' (since that would cause a segfault).

If we are considering the precise lifetime scenario though, this is not
correct. In such a situation, we *DO* care about the previous sequence, but
additionally, we wish to track the uses resulting from the following incomplete
sequences:

  Retain -> CanRelease -> Release   (TopDown)
  Retain <- Use <- Release          (BottomUp)

*NOTE* This patch looks large but the most of it consists of updating
test cases. Additionally this fix exposed an additional bug. I removed
the test case that expressed said bug and will recommit it with the fix
in a little bit.

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

Reapply r178845 with fix - Fix bug in PEI's virtual-register scavenging

This fixes PEI as previously described, but correctly handles the case where
the instruction defining the virtual register to be scavenged is the first in
the block. Arnold provided me with a bugpoint-reduced test case, but even that
seems too large to use as a regression test. If I'm successful in cleaning it
up then I'll commit that as well.

Original commit message:

    This change fixes a bug that I introduced in r178058. After a register is
    scavenged using one of the available spills slots the instruction defining the
    virtual register needs to be moved to after the spill code. The scavenger has
    already processed the defining instruction so that registers killed by that
    instruction are available for definition in that same instruction. Unfortunately,
    after this, the scavenger needs to iterate through the spill code and then
    visit, again, the instruction that defines the now-scavenged register. In order
    to avoid confusion, the register scavenger needs the ability to 'back up'
    through the spill code so that it can again process the instructions in the
    appropriate order. Prior to this fix, once the scavenger reached the
    just-moved instruction, it would assert if it killed any registers because,
    having already processed the instruction, it believed they were undefined.

    Unfortunately, I don't yet have a small test case. Thanks to Pranav Bhandarkar
    for diagnosing the problem and testing this fix.

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

Use the target options specified on a function to reset the back-end.

During LTO, the target options on functions within the same Module may
change. This would necessitate resetting some of the back-end. Do this for X86,
because it's a Friday afternoon.

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

Revert r178845 - Fix bug in PEI's virtual-register scavenging

Reverting because this breaks one of the LTO builders. Original commit message:

    This change fixes a bug that I introduced in r178058. After a register is
    scavenged using one of the available spills slots the instruction defining the
    virtual register needs to be moved to after the spill code. The scavenger has
    already processed the defining instruction so that registers killed by that
    instruction are available for definition in that same instruction. Unfortunately,
    after this, the scavenger needs to iterate through the spill code and then
    visit, again, the instruction that defines the now-scavenged register. In order
    to avoid confusion, the register scavenger needs the ability to 'back up'
    through the spill code so that it can again process the instructions in the
    appropriate order. Prior to this fix, once the scavenger reached the
    just-moved instruction, it would assert if it killed any registers because,
    having already processed the instruction, it believed they were undefined.

    Unfortunately, I don't yet have a small test case. Thanks to Pranav Bhandarkar
    for diagnosing the problem and testing this fix.

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

Tidy up a bit. No functional change.

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

Disable the optimization about promoting vector-element-access with symbolic index.

This optimization is unstable at this moment; it
  1) block us on a very important application
  2) PR15200
  3) test6 and test7 in test/Transforms/ScalarRepl/dynamic-vector-gep.ll
     (the CHECK command compare the output against wrong result)

   I personally believe this optimization should not have any impact on the
autovectorized code, as auto-vectorizer is supposed to put gather/scatter
in a "right" way.  Although in theory downstream optimizaters might reveal
some gather/scatter optimization opportunities, the chance is quite slim.

   For the hand-crafted vectorizing code, in term of redundancy elimination,
load-CSE, copy-propagation and DSE can collectively achieve the same result,
but in much simpler way. On the other hand, these optimizers are able to
improve the code in a incremental way; in contrast, SROA is sort of all-or-none
approach. However, SROA might slighly win in stack size, as it tries to figure
out a stretch of memory tightenly cover the area accessed by the dynamic index.

 rdar://13174884
 PR15200

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

[mips] XFAIL test-interp-vec-loadstore.ll in an attempt to turn builder
llvm-mips-linux green.

llvm-mips-linux runs on a big endian machine. This test passes if I change 'e'
to 'E' in the target data layout string.

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

<rdar://problem/13551789> Fix a race in the LockFileManager.

It's possible for the lock file to disappear and the owning process to
return before we're able to see the generated file. Spin for a little
while to see if it shows up before failing.

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

<rdar://problem/13551789> Fix yet another race in unique_file.

If the directory that will contain the unique file doesn't exist when
we tried to create the file, but another process creates it before we
get a chance to try creating it, we would bail out rather than try to
create the unique file.

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

[Support][FileSystem] Fix identify_magic for big endian ELF.

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

Move yaml2obj to tools too.

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

Define versions of Section that are explicitly marked as little endian.

These should really be templated like ELF, but this is a start.

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

Added two debug logging messages to VisitInstructionsTopDown to match VisitInstructionsBottomUp.

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

Don't use InMemoryStruct in getSection and getSection64.

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

Cleaned up whitespace and made debug logging less verbose.

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

Make the test/CodeGen/X86/win32_sret.ll reliable on any CPU by explicitly specifying the -mcpu

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

Reverting 178851 as it broke buildbots

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

[ms-inline asm] Add support for numeric displacement expressions in bracketed
memory operands.

Essentially, this layers an infix calculator on top of the parsing state
machine.  The scale on the index register is still expected to be an immediate

 __asm mov eax, [eax + ebx*4]

and will not work with more complex expressions.  For example,

 __asm mov eax, [eax + ebx*(2*2)]

The plus and minus binary operators assume the numeric value of a register is
zero so as to not change the displacement.  Register operands should never
be an operand for a multiply or divide operation; the scale*indexreg
expression is always replaced with a zero on the operand stack to prevent
such a case.
rdar://13521380

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

[Support] Disable assertion dialogs from the MSVC debug CRT

Summary:
Sets a report hook that emulates pressing "retry" in the "abort, retry,
ignore" dialog box that _CrtDbgReport normally raises.  There are many
other ways to disable assertion reports, but this was the only way I
could find that still calls our exception handler.

Reviewers: Bigcheese

CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D625

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

Use ScalarBitSetTraits.

What was missing was were the type strong operator|.

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

Fix include guards to match new location.

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

Don't fetch pointers from a InMemoryStruct.

InMemoryStruct is extremely dangerous as it returns data from an internal
buffer when the endiannes doesn't match. This should fix the tests on big
endian hosts.

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

Enable JIT/MCJIT unit tests for targets with JIT support.
Change unittests/ExecutionEngine/Makefile to include Makefile.config before
TARGET_HAS_JIT flag is checked.

Fixes bug: http://llvm.org/bugs/show_bug.cgi?id=15669

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

Respect Addend when processing MCJIT relocations to local/global symbols.

When the RuntimeDyldELF::processRelocationRef routine finds the target
symbol of a relocation in the local or global symbol table, it performs
a section-relative relocation:

    Value.SectionID = lsi->second.first;
    Value.Addend = lsi->second.second;

At this point, however, any Addend that might have been specified in
the original relocation record is lost.  This is somewhat difficult to
trigger for relocations within the code section since they usually
do not contain non-zero Addends (when built with the default JIT code
model, in any case).  However, the problem can be reliably triggered
by a relocation within the data section caused by code like:

 int test[2] = { -1, 0 };
 int *p = &test[1];

The initializer of "p" will need a relocation to "test + 4".  On
platforms using RelA relocations this means an Addend of 4 is required.
Current code ignores this addend when processing the relocation,
resulting in incorrect execution.

Fixed by taking the Addend into account when processing relocations
to symbols found in the local or global symbol table.

Tested on x86_64-linux and powerpc64-linux.

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

llvm-symbolizer: correctly parse filenames given in quotes

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

Add a basic test for llvm-symbolizer tool

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

Buildbot fix for r178851: mistake was in wrong TargetRegisterInfo::getRegClass usage.

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

Add obj2yaml to test dependencies

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

Fix for PR14824: "Optimization arm_ldst_opt inserts newly generated instruction vldmia at incorrect position".
Patch introduces memory operands tracking in ARMLoadStoreOpt::LoadStoreMultipleOpti. For each register it keeps the order of load operations as it was before optimization pass.
It is kind of deep improvement of fix proposed by Hao: http://llvm.org/bugs/show_bug.cgi?id=14824#c4
But it also tracks conflicts between different register classes (e.g. D2 and S5).
For more details see:
Bug description: http://llvm.org/bugs/show_bug.cgi?id=14824
LLVM Commits discussion:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130311/167936.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130318/168688.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130325/169376.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130401/170238.html

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

Add a SchedMachineModel for the PPC G5

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

The ppc bots say this is the last broken line, so lets try one more :-(

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

Add a SchedMachineModel for the PPC A2

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

One more try before I just delete the macho bits until tomorrow.

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

Fix bug in PEI's virtual-register scavenging

This change fixes a bug that I introduced in r178058. After a register is
scavenged using one of the available spills slots the instruction defining the
virtual register needs to be moved to after the spill code. The scavenger has
already processed the defining instruction so that registers killed by that
instruction are available for definition in that same instruction. Unfortunately,
after this, the scavenger needs to iterate through the spill code and then
visit, again, the instruction that defines the now-scavenged register. In order
to avoid confusion, the register scavenger needs the ability to 'back up'
through the spill code so that it can again process the instructions in the
appropriate order. Prior to this fix, once the scavenger reached the
just-moved instruction, it would assert if it killed any registers because,
having already processed the instruction, it believed they were undefined.

Unfortunately, I don't yet have a small test case. Thanks to Pranav Bhandarkar
for diagnosing the problem and testing this fix.

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

ARM scheduler model: Add scheduler info to more instructions and resource
descriptions for compares

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

More test loosening.

Sorry for so many commits, but llvm is still building on my ppc vm.

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

ARM scheduler model: Swift has varying latencies, uops for simple ALU ops

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

Loosen this test too.

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

Loosen this test.

Looks like there is a big endian/little endian problem here. Loosen the
test to try to get the bots green while llvm builds on a ppc qemu vm.

The failure was in http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/

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

Remove empty directory.

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

Move obj2yaml to tools to sort out make's dependencies.

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

Build obj2yaml with configure+make.

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

Add a test for obj2yaml in preparation for refactoring it.

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

Clean up some confusing language, and use more realistic examples.

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

RegisterPressure heuristics currently require signed comparisons.

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

Disable DFSResult for ConvergingScheduler.

For now, just save the compile time since the ConvergingScheduler
heuristics don't use this analysis. We'll probably enable it later
after compile-time investigation.

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

MachineScheduler: format DEBUG output.

I'm getting more serious about tuning and enabling on x86/ARM. Start
by making the trace readable.

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

LoopVectorizer: Pass OperandValueKind information to the cost model

Pass down the fact that an operand is going to be a vector of constants.

This should bring the performance of MultiSource/Benchmarks/PAQ8p/paq8p on x86
back. It had degraded to scalar performance due to my pervious shift cost change
that made all shifts expensive on x86.

radar://13576547

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

X86 cost model: Differentiate cost for vector shifts of constants

SSE2 has efficient support for shifts by a scalar. My previous change of making
shifts expensive did not take this into account marking all shifts as expensive.
This would prevent vectorization from happening where it is actually beneficial.

With this change we differentiate between shifts of constants and other shifts.

radar://13576547

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

CostModel: Add parameter to instruction cost to further classify operand values

On certain architectures we can support efficient vectorized version of
instructions if the operand value is uniform (splat) or a constant scalar.
An example of this is a vector shift on x86.

We can efficiently support

for (i = 0 ; i < ; i += 4)
  w[0:3] = v[0:3] << <2, 2, 2, 2>

but not

for (i = 0; i < ; i += 4)
  w[0:3] = v[0:3] << x[0:3]

This patch adds a parameter to getArithmeticInstrCost to further qualify operand
values as uniform or uniform constant.

Targets can then choose to return a different cost for instructions with such
operand values.

A follow-up commit will test this feature on x86.

radar://13576547

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

Debug Info: revert 178722 for now.

There is a difference for FORM_ref_addr between DWARF 2 and DWARF 3+.
Since Eric is against guarding DWARF 2 ref_addr with DarwinGDBCompat, we are
still in discussion on how to handle this.

The correct solution is to update our header to say version 4 instead of version
2 and update tool chains as well.

rdar://problem/13559431

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

typo

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

Rename the current PPC BCL definition to BCLalways

BCL is normally a conditional branch-and-link instruction, but has
an unconditional form (which is used in the SjLj code, for example).
To make clear that this BCL instruction definition is specifically
the special unconditional form (which does not meaningfully take
a condition-register input), rename it to BCLalways.

No functionality change intended.

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

PPC: Improve code generation for mixed-precision reciprocal sqrt

The DAGCombine logic that recognized a/sqrt(b) and transformed it into
a multiplication by the reciprocal sqrt did not handle cases where the
sqrt and the division were separated by an fpext or fptrunc.

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

Hexagon: Expand br_cc.

It fixes following tests for Hexagon:

CodeGen/Generic/2003-07-29-BadConstSbyte.ll
CodeGen/Generic/2005-10-21-longlonggtu.ll
CodeGen/Generic/2009-04-28-i128-cmp-crash.ll
CodeGen/Generic/MachineBranchProb.ll
CodeGen/Generic/builtin-expect.ll
CodeGen/Generic/pr12507.ll

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

Reassociate: Avoid iterator invalidation.

OpndPtrs stored pointers into the Opnd vector that became invalid when the
vector grows. Store indices instead. Sadly I only have a large testcase that
only triggers under valgrind, so I didn't include it.

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

Disable 2010-10-01-crash.ll for Hexagon as the Hexagon frontend will
never produce a byval parameter with size < 8 bytes.

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

Add back parsing of header charactestics.

It had been dropped during the switch to yaml::IO. Also add a test going
from yaml2obj to llvm-readobj. It can be extended as we add more
fields/formats to yaml2obj.

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

[XCore] Add bru instruction.

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

[XCore] The RRegs register class is a superset of GRRegs.

At the time when the XCore backend was added there were some issues with
with overlapping register classes but these all seem to be fixed now.
Describing the register classes correctly allow us to get rid of a
codegen only instruction (LDAWSP_lru6_RRegs) and it means we can
disassemble ru6 instructions that use registers above r11.

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

Missing word

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

Avoid high-latency false CPSR dependencies even for tMOVSi.

The Thumb2SizeReduction pass avoids false CPSR dependencies, except it
still aggressively creates tMOVi8 instructions because they are so
common.

Avoid creating false CPSR dependencies even for tMOVi8 instructions when
the the CPSR flags are known to have high latency. This allows integer
computation to overlap floating point computations.

Also process blocks in a reverse post-order and propagate high-latency
flags to successors.

<rdar://problem/13468102>

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

Formatting

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

Revert r178713

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

New-password-test commit.

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

R600: Use a mask for offsets when encoding instructions

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

R600: Fix wrong address when substituting ENDIF

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

R600: Take export into account when computing cf address

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

Propagate path to ASan/MSan symbolizer into test environment to produce useful reports on errors.

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

Document the return value of SmallSet insert.

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

Add SPARC v9 support for select on 64-bit compares.

This requires v9 cmov instructions using the %xcc flags instead of the
%icc flags.

Still missing:
- Select floats on %xcc flags.
- Select i64 on %fcc flags.

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

Explicitly add -Wl,--export-all-symbols on mingw/cygwin.

Looks like cmake on windows is not expanding ENABLE_EXPORTS to
-Wl,--export-all-symbols on mingw or cygwin, so add this back.

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

Don't export symbols in every binary on linux.

On freebsd this makes sure that symbols are exported on the binaries that need
them. The net result is that we should get symbols in the binaries that need
them on every platform.

On linux x86-64 this reduces the size of the bin directory from 262MB to 250MB.

Patch by Stephen Checkoway.

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

Debug Info: according to DWARF 2, FORM_ref_addr the same size as an address on
the target system.

It was hard-coded to 4 bytes before. I can't get llvm to generate a
ref_addr on a reasonably sized testing case.

rdar://problem/13559431

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

Refactored out the helper method FindPredecessorAutoreleaseWithSafePath from ObjCARCOpt::OptimizeReturns.

Now ObjCARCOpt::OptimizeReturns is easy to read and reason about.

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

Refactored out the helper function FindPredecessorRetainWithSafePath from ObjCARCOpt::OptimizeReturns.

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

Make it possible to include llvm-c without including C++ headers. Patch by Filip Pizlo.

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

Small cleanups.

Cleaned up trailing whitespace and added extra slashes in front of a
function level comment so that it follow the convention of having 3
slashes.

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