The LDD/STD instructions can load/store a 64bit quantity from/to
memory to/from a consecutive even/odd pair of (32-bit) registers. They
are part of SparcV8, and also present in SparcV9. (Although deprecated
there, as you can store 64bits in one register).

As recommended on llvmdev in the thread "How to enable use of 64bit
load/store for 32bit architecture" from Apr 2015, I've modeled the
64-bit load/store operations as working on a v2i32 type, rather than
making i64 a legal type, but with few legal operations. The latter
does not (currently) work, as there is much code in llvm which assumes
that if i64 is legal, operations like "add" will actually work on it.

The same assumption does not hold for v2i32 -- for vector types, it is
workable to support only load/store, and expand everything else.

This patch:
- Adds a new register class, IntPair, for even/odd pairs of registers.

- Modifies the list of reserved registers, the stack spilling code,
  and register copying code to support the IntPair register class.

- Adds support in AsmParser. (note that in asm text, you write the
  name of the first register of the pair only. So the parser has to
  morph the single register into the equivalent paired register).

- Adds the new instructions themselves (LDD/STD/LDDA/STDA).

- Hooks up the instructions and registers as a vector type v2i32. Adds
  custom legalizer to transform i64 load/stores into v2i32 load/stores
  and bitcasts, so that the new instructions can actually be
  generated, and marks all operations other than load/store on v2i32
  as needing to be expanded.

- Copies the unfortunate SelectInlineAsm hack from ARMISelDAGToDAG.
  This hack undoes the transformation of i64 operands into two
  arbitrarily-allocated separate i32 registers in
  SelectionDAGBuilder. and instead passes them in a single
  IntPair. (Arbitrarily allocated registers are not useful, asm code
  expects to be receiving a pair, which can be passed to ldd/std.)

Also adds a bunch of test cases covering all the bugs I've added along
the way.

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

llvm-svn: 244484

llvm-svn: 244483

llvm-svn: 244482

I looked into adding a warning / error for this to FileCheck, but there doesn't
seem to be a good way to avoid it triggering on the instances of it in RUN lines.

llvm-svn: 244481

llvm-svn: 244480

llvm-svn: 244479

llvm-svn: 244478

It was already working, but missing a test.

llvm-svn: 244477

llvm-svn: 244476

llvm-svn: 244475

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

llvm-svn: 244474

cl uses 'CL' and '_CL_' to prepend and append command line options to
the given argument vector.  There is an additional quirk whereby '#' is
transformed into '='.

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

llvm-svn: 244473

llvm-svn: 244472

llvm-svn: 244471

variable initialization from its usage in the push_back making
collapse of the two statements unlikely even without a comment.

llvm-svn: 244470

Previously all test output was reported by each individual
instance of dotest.py.  After a recent patch, dosep gets dotest
outptu via a pipe, and selectively decides which output to
print.

This breaks certain scripts which rely on having full output
of each dotest instance to do various parsing and/or log-scraping.

While we make no promises about the format of dotest output, it's
easy to restore this to the old behavior for now, although it is
behind a flag.  To re-enable full output, run dosep.py with the -s
option.

Differential Revision: http://reviews.llvm.org/D11816
Reviewed By: Chaoren Lin

llvm-svn: 244469

These changes are for Android x86_64 targets to be compatible
with current Android g++ and conform to AMD64 ABI.

https://llvm.org/bugs/show_bug.cgi?id=23897
  * Return type of long double (fp128) should be fp128, not x86_fp80.
  * Vararg of long double (fp128) could be in register and overflowed to memory.

https://llvm.org/bugs/show_bug.cgi?id=24111
  * Return value of long double (fp128) _Complex should be in memory like a structure of {fp128,fp128}.

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

llvm-svn: 244468

This change adds the new unroll metadata "llvm.loop.unroll.enable" which directs
the optimizer to unroll a loop fully if the trip count is known at compile time, and
unroll partially if the trip count is not known at compile time. This differs from
"llvm.loop.unroll.full" which explicitly does not unroll a loop if the trip count is not
known at compile time

With this change "#pragma unroll" generates "llvm.loop.unroll.enable" rather than
"llvm.loop.unroll.full" metadata. This changes the semantics of "#pragma unroll" slightly
to mean "unroll aggressively (fully or partially)" rather than "unroll fully or not at all".

The motivating example for this change was some internal code with a loop marked
with "#pragma unroll" which only sometimes had a compile-time trip count depending
on template magic. When the trip count was a compile-time constant, everything works
as expected and the loop is fully unrolled. However, when the trip count was not a
compile-time constant the "#pragma unroll" explicitly disabled unrolling of the loop(!).
Removing "#pragma unroll" caused the loop to be unrolled partially which was desirable
from a performance perspective.

llvm-svn: 244467

This change adds the unroll metadata "llvm.loop.unroll.enable" which directs
the optimizer to unroll a loop fully if the trip count is known at compile time, and
unroll partially if the trip count is not known at compile time. This differs from
"llvm.loop.unroll.full" which explicitly does not unroll a loop if the trip count is not
known at compile time.

The "llvm.loop.unroll.enable" is intended to be added for loops annotated with
"#pragma unroll".

llvm-svn: 244466

llvm-svn: 244465

llvm-svn: 244464

llvm-svn: 244463

llvm-svn: 244462

llvm-svn: 244461

llvm-svn: 244460

  With a deque (or any other sequential container) it is not sound to
  take the address of the elements when the container is still under
  construction. With a pointer based container this is save.

llvm-svn: 244459

llvm-svn: 244458

llvm-svn: 244457

The PHI node with multiple incoming edges from inside the region.

Thanks Tobias for coming up with the example. 

llvm-svn: 244456

llvm-svn: 244455

We couldn't calculate the removal ranges properly at this point.

llvm-svn: 244454

Summary: I've copy/pasted the LLVM_NOEXCEPT definition macro goo from LLVM's Compiler.h. Is there somewhere I should put this in Compiler RT? Is there a useful header to define/share things like this?

Reviewers: samsonov

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

llvm-svn: 244453

llvm-svn: 244452

llvm-svn: 244451

The function to which this commit applies has been removed in a
previous commit.

llvm-svn: 244450

Summary:
This adds a hook to TTI which enables us to selectively turn on by default
interleaved access vectorization for targets on which we have have performed
the required benchmarking.

Reviewers: rengolin

Subscribers: rengolin, llvm-commits

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

llvm-svn: 244449

The scalarizer can cache incorrect entries when walking up a chain of
insertelement instructions. This occurs when it encounters more than one
instruction that it is not actively searching for, as it unconditionally caches
every element it finds. The fix is to only cache the first element that it
isn't searching for so we don't overwrite correct entries.

Reviewers: hfinkel

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

llvm-svn: 244448

llvm-svn: 244447

Summary:
Add brace style `BS_WebKit` as described on https://www.webkit.org/coding/coding-style.html:

* Function definitions: place each brace on its own line.
* Other braces: place the open brace on the line preceding the code block; place the close brace on its own line.

Set brace style used in `getWebKitStyle()` to the newly added `BS_WebKit`.

Reviewers: djasper, klimek

Subscribers: klimek, cfe-commits

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

llvm-svn: 244446

llvm-svn: 244445