One performs: (X == 13 | X == 14) -> X-13 <u 2
The other: (A == C1 || A == C2) -> (A & ~(C1 ^ C2)) == C1

The problem is that there are certain values of C1 and C2 that
trigger both transforms but the first one blocks out the second,
this generates suboptimal code.

Reordering the transforms should be better in every case and
allows us to do interesting stuff like turn:
  %shr = lshr i32 %X, 4
  %and = and i32 %shr, 15
  %add = add i32 %and, -14
  %tobool = icmp ne i32 %add, 0

into:
  %and = and i32 %X, 240
  %tobool = icmp ne i32 %and, 224

llvm-svn: 179493

llvm-svn: 179492

or non-trivial destructor.

llvm-svn: 179491

llvm-svn: 179490

llvm-svn: 179489

llvm-svn: 179488

AddTargetFeature() routine to handle -msingle-float / -mdouble-float
options.

llvm-svn: 179487

independent of float ABI feature in the MipsTargetInfoBase class.

llvm-svn: 179486

We do not only need to understand that 'k * p' is a parameter expression, but
also need to store this expression in the set of parameters. Before this patch
we wrongly stored the two individual parameters %k and %p.

Reported by: Sebastian Pop <spop@codeaurora.org>

llvm-svn: 179485

llvm-svn: 179484

llvm-svn: 179483

Invalid redeclarations of valid explicit declarations shouldn't
take the same path as redeclarations of implicit declarations,
and invalid local extern declarations shouldn't foul things up
for everybody else.

llvm-svn: 179482

two new options –msingle-float and –mdouble-float. These options can be
used simultaneously with float ABI selection options (-mfloat-abi,
-mhard-float, -msoft-float). They mark whether a floating-point
coprocessor supports double-precision operations.

llvm-svn: 179481

llvm-svn: 179480

llvm-svn: 179479

llvm-svn: 179478

Test case by llvm-stress.

llvm-svn: 179477

llvm-svn: 179476

SLPVectorizer: Add support for trees that don't start at binary operators, and add the cost of extracting values from the roots of the tree.

llvm-svn: 179475

For when 16 TB just isn't enough.

llvm-svn: 179474

This is the default model for non-PIC 64-bit code. It supports
text+data+bss linked anywhere in the low 16 TB of the address space.

llvm-svn: 179473

64-bit code models need multiple relocations that can't be inferred from
the opcode like they can in 32-bit code.

llvm-svn: 179472

Constant pool entries are accessed exactly the same way as global
variables.

llvm-svn: 179471

llvm-svn: 179470

This fixes the pic32 code model for SPARC v9.

llvm-svn: 179469

SDNodes and MachineOperands get target flags representing the %hi() and
%lo() assembly annotations that eventually become relocations.

Also define flags to be used by the 64-bit code models.

llvm-svn: 179468

Accidentally disallowed explicit tuple conversions when all elements of the tuple can be explicitly converted.

llvm-svn: 179467

- Do not add symbols with no names
- Make sure that symbols from ELF symbol tables know that the byte size is correct. Previously the symbols would calculate their sizes by looking for the next symbol and take symbols that had zero size and make them have invalid sizes.
- Added the ability to dump raw ELF symbols by adding a Dump method to ELFSymbol

Also removed some unused code from lldb_private::Symtab.

llvm-svn: 179466

Leaving MFCR has having unmodeled side effects is not enough to prevent
unwanted instruction reordering post-RA. We could probably apply a stronger
barrier attribute, but there is a better way: Add all (not just the first) CR
to be spilled as live-in to the entry block, and add all CRs to the MFCR
instruction as implicitly killed.

Unfortunately, I don't have a small test case.

llvm-svn: 179465

I have checked that the test still fails when the "|| !P.isRegularFile()" from
the original patch is removed.

llvm-svn: 179464

Currently, only abs32 and pic32 are implemented. Add a test case for
abs32 with 64-bit code. 64-bit PIC code is currently broken.

llvm-svn: 179463

It doesn't seem like anybody is checking types this late in isel, so no
test case.

llvm-svn: 179462

llvm-svn: 179461

There is a Constant with non-constant operands: blockaddress.

llvm-svn: 179460

Remove the useless SRCROOT declaration from the call of build-swig-wrapper-classes.sh & finish-swig-wrapper-classes.sh

Two reasons for that:
* the declaration is not used. the LLDB_SOURCE_DIR is provided as the first argument in the script ($1) (called SRC_ROOT in the source code)
* add_custom_command is quoting the first argument of the command. Usually, it is the script itself (and then the full path to the script) but, here, it is the declaration of a variable.
It was failing with:
cd "/llvm-toolchain-3.3~svn179457/build-llvm/tools/lldb/scripts" && "SRCROOT=/llvm-toolchain-3.3~svn179457/tools/lldb" /llvm-toolchain-3.3~svn179457/tools/lldb/scripts/build-swig-wrapper-classes.sh /llvm-toolchain-3.3~svn179457/tools/lldb /llvm-toolchain-3.3~svn179457/build-llvm/tools/lldb/scripts /llvm-toolchain-3.3~svn179457/build-llvm/tools/lldb/scripts /llvm-toolchain-3.3~svn179457/build-llvm -m
/bin/sh: 1: SRCROOT=/llvm-toolchain-3.3~svn179457/tools/lldb: not found

llvm-svn: 179459

This is basically the same fix in three different places. We use a set to avoid
walking the whole tree of a big ConstantExprs multiple times.

For example: (select cmp, (add big_expr 1), (add big_expr 2))
We don't want to visit big_expr twice here, it may consist of thousands of
nodes.

The testcase exercises this by creating an insanely large ConstantExprs out of
a loop. It's questionable if the optimizer should ever create those, but this
can be triggered with real C code. Fixes PR15714.

llvm-svn: 179458

For functions that need to spill CRs, and have dynamic stack allocations, the
value of the SP during the restore is not what it was during the save, and so
we need to use the FP in these cases (as for all of the other spills and
restores, but the CR restore has a special code path because its reserved slot,
like the link register, is specified directly relative to the adjusted SP).

llvm-svn: 179457

The order of copies depends on queue order, which is not very stable.

llvm-svn: 179456

llvm-svn: 179455

llvm-svn: 179454