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

This option expands shown relocations from single line to a dictionary
format:

  Relocation {
    Offset: 0x4
    Type: R_386_32 (1)
    Symbol: sym
    Info: 0x0
  }

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

This test ensures that relocation type names returned by libObject match
the raw relocation type value.

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

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

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

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

…implied by the driver

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

…g answers for blocks larger than 3 instrs.

Also add a unit test. PR15727.

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

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

You can't copy an OwningPtr, and move semantics aren't available in C++98.


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

It turns out some platforms (e.g. Windows) lay out their llvm-mc slightly
differently with extra newlines; there was no real reason for the test lines to
be consecutive, so this relaxes the FileCheck.

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

These tests rely specifically on the names of ELF relocations, let alone any
other detail. There's no way they'd work if LLVM was emitting something else by
default.

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

Don't classify idiv/udiv as a reduction operation. Integer division is lossy.
For example : (1 / 2) * 4 != 4/2.

Example:

int a[] = { 2, 5, 2, 2}
int x = 80;

for()
  x /= a[i];

Scalar:
  x /= 2 // = 40
  x /= 5 // = 8
  x /= 2 // = 4
  x /= 2 // = 2

Vectorized:

 <80, 1> / <2,5> //= <40,0>
 <40, 0> / <2,2> //= <20,0>

 20*0 = 0

radar://13640654

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

… was added

in r179325.  Test case coming shortly on the clang side.
Part of rdar://13453209

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

The transform will execute like so:
(A & ~B) == 0 --> (A & B) != 0
(A & ~B) != 0 --> (A & B) == 0


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

…ated predication.

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

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

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

TableGen will not combine nested list 'let' bindings into a single list, and
instead uses only the inner scope. As a result, several instruction definitions
were missing implicit register defs that were in outer scopes. This de-nests
these scopes and makes all instructions have only one let binding which sets
implicit register definitions.

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

…nd an

immediate displacement.  Specifically, add support for generating the proper IR.
We've been able to parse this for some time now.  Test case to be added on the
clang side.
Part of rdar://13453209


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

According to the ARM reference manual, constant offsets are mandatory for pre-indexed addressing modes.
The MC disassembler was not obeying this when the offset is 0.
It was producing instructions like: str r0, [r1]!.
Correct syntax is: str r0, [r1, #0]!.

This change modifies the dumping of operands so that the offset is always printed, regardless of its value, when pre-indexed addressing mode is used.

Patch by Mihail Popa <Mihail.Popa@arm.com>


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

…ogic. This

is a follow on to r179393.  Test case to be added on the clang side.
Part of rdar://13453209


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

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

…inside the source test root.

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

is a follow on to r179393 and r179399.  Test case to be added on
the clang side.
Part of rdar://13453209


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

…pplicable

when parsing MS-style inline assembly.  No functional change intended.


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

patch by Veselov, Yuri <Yuri.Veselov@intel.com>.



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

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

…ations from 1 to two. Fixed a few tests that changes because now the cost of one insert + a vector operation on two doubles is lower than two scalar operations on doubles.

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

… We now perform a preliminary traversal of the graph to collect values with multiple users and check where the users came from.

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

Fixes PR15737.

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

…bots fail.

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

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

instructions.



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

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

…tional

change intended.  Test case previously added in r178568.
Part of rdar://13611297

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

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

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

We are now able to handle big endian macho files in llvm-readobject. Thanks to
David Fang for providing the object files.

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

Should fix the bots.

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

lowerINTRINSIC_WO_CHAIN into MipsSETargetLowering.

No functionality changes.


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

I hope this brings http://lab.llvm.org:8011/builders/clang-x86_64-darwin11-self-mingw32 back.

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

I need to handle this for the test case in my following scheduler
commit.

Work is already under way to redesign the mechanism for node order
propagation because this case by case approach is unmaintainable.

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

The register allocator expects minimal physreg live ranges. Schedule
physreg copies accordingly. This is slightly tricky when they occur in
the middle of the scheduling region. For now, this is handled by
rescheduling the copy when its associated instruction is
scheduled. Eventually we may instead bundle them, but only if we can
preserve the bundles as parallel copies during regalloc.

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

The initial values were arbitrary. I want them to be more
conservative. This represents the number of latency cycles hidden by
OOO execution. In practice, I think it should be within a small factor
of the complex floating point operation latency so the scheduler can
make some attempt to hide latency even for smallish blocks.

These are by no means the best values, just a starting point for
tuning heuristics. Some benchmarks such as TSVC run faster with this
lower value for SandyBridge. I haven't run anything on Haswell, but
it's shouldn't be 2x SB.

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

…attempt to check for a variant.

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

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

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

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

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

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

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).

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

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.

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

…hes.

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

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

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

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

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

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

…priately

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.

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

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.

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

This fixes the pic32 code model for SPARC v9.

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

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

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

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

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

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

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.

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

For when 16 TB just isn't enough.

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

…tors, and add the cost of extracting values from the roots of the tree.

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

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

Test case by llvm-stress.

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

…uch as integers.

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

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

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

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

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

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


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

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

and use that as the default triple for the module and target
data layout.

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

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

This reverts commit r179497 and the accompanying commit as it broke random platforms that aren't osx.

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

This fixes an ABI bug for non-Darwin PPC64. For the callee-saved condition
registers, the spill location is specified relative to the stack pointer (SP +
8). However, this is not relative to the SP after the new stack frame is
established, but instead relative to the caller's stack pointer (it is stored
into the linkage area of the parent's stack frame).

So, like with the link register, we don't directly spill the CRs with other
callee-saved registers, but just mark them to be spilled during prologue
generation.

In practice, this reverts r179457 for PPC64 (but leaves it in place for PPC32).

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

Now that the CR spilling issues have been resolved, we can remove the
unmodeled-side-effect attributes from the comparison instructions (and also
mark them as isCompare). By allowing these, by default, to have unmodeled side
effects, we were hiding problems with CR spilling; but everything seems much
happier now.

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

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

…e instructions.

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

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

…. Make -fslp-vectorize run the slp-vectorizer.

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

…t the -fslp-vectorize-aggressive flag.

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

…leases.

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

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

I can fix the testcases here:

http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/6952

This reverts commit r179512 due to testcases specifying triples
that they didn't actually mean and causing failures on other platforms.

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

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

This is a rework of the broken parts in r179373 which were subsequently reverted in r179374 due to incompatibility with C++98 compilers.  This version should be ok under C++98.

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

I will remove the isBigEndianHost function once I update clang.

The ifdef logic is designed to
* not use configure/cmake to avoid breaking -arch i686 -arch ppc.
* default to little endian
* be as small as possible

It looks like sys/endian.h is the preferred header on most modern BSD systems,
but it is better to change this in a followup patch as machine/endian.h is
available on FreeBSD, OpenBSD, NetBSD and OS X.

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

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

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

…ess.

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

Patch by Cameron McInally <cameron.mcinally@nyu.edu>.

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

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

No content changes.


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

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

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

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

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

Instead of emitting config values in a predefined order, the code
emitter will now emit a 32-bit register index followed by the 32-bit
config value.

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