Commit Graph

106030 Commits

Author SHA1 Message Date
Daniel Sanders
11fcd25eb7 Merged from r217434:
[mips] Don't cache IsO32 and IsFP64 in MipsTargetLowering::MipsCC

Summary:
Use a MipsSubtarget reference instead.

No functional change.

Reviewers: vmedic

Reviewed By: vmedic

Subscribers: llvm-commits

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




git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223013 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-01 13:15:04 +00:00
Daniel Sanders
cb3c315c96 Merged from r215640:
[mips] Improve robustness of some tests.

Summary:
This is done by removing some hardcoded registers like $at or expecting a single digit register to be selected.

Contains work done by Matheus Almeida.

Reviewers: matheusalmeida, dsanders

Reviewed By: dsanders

Subscribers: tomatabacu

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223012 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-01 11:43:13 +00:00
Daniel Sanders
f1f5c3baed Merged from r215211:
[mips] Invert the abicalls feature bit to be noabicalls so that it's possible for -mno-abicalls to take effect.

Also added the testcase that should have been in r215194.

This behaviour has surprised me a few times now. The problem is that the
generated MipsSubtarget::ParseSubtargetFeatures() contains code like this:

   if ((Bits & Mips::FeatureABICalls) != 0) IsABICalls = true;

so '-abicalls' means 'leave it at the default' and '+abicalls' means 'set it to
true'. In this case, (and the similar -modd-spreg case) I'd like the code to be

  IsABICalls = (Bits & Mips::FeatureABICalls) != 0;

or possibly:

   if ((Bits & Mips::FeatureABICalls) != 0)
     IsABICalls = true;
   else
     IsABICalls = false;

and preferably arrange for 'Bits & Mips::FeatureABICalls' to be true by default
(on some triples).




git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223011 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-01 11:38:38 +00:00
Daniel Sanders
3b09b1f496 Merged from r215194:
[mips] Initial implementation of -mabicalls/-mno-abicalls.

This patch implements the main rules for -mno-abicalls such as reserving $gp,
and emitting the correct .option directive.

Patch by Matheus Almeida and Toma Tabacu

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223009 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-01 11:32:07 +00:00
Daniel Sanders
da5b8f2252 Merged from r214578:
llvm/test/CodeGen/Mips/cconv/arguments-varargs.ll: Add explicit -mtriple=(mips|mipsel)-linux on 4 lines.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223008 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-01 11:23:40 +00:00
Daniel Sanders
ae5e83adbd Merged from r214493:
[mips][PR19612] Fix va_arg for big-endian mode.

Summary:
Big-endian mode was not correctly adjusting the offset for types smaller
than an ABI slot.

Fixes PR19612

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: sstankovic, llvm-commits

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@223007 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-01 11:22:34 +00:00
Daniel Sanders
9290cd66a8 Merging r217257:
------------------------------------------------------------------------
r217257 | tomatabacu | 2014-09-05 17:32:09 +0100 (Fri, 05 Sep 2014) | 9 lines

[mips] Change Feature-related types from unsigned to uint64_t in MipsAsmParser. No functional changes.

Summary: Found a couple of cases where unsigned was still being used. These two should be the last ones in the (entire) Mips backend.

Reviewers: dsanders

Reviewed By: dsanders

Differential Revision: http://reviews.llvm.org/D5028
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@222875 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-27 10:55:46 +00:00
Daniel Sanders
7bea0cea87 Merging r218745:
------------------------------------------------------------------------
r218745 | dsanders | 2014-10-01 09:26:55 +0100 (Wed, 01 Oct 2014) | 7 lines

[mips] Fix disassembly of [ls][wd]c[23], cache, and pref                          
                                                                                  
Fixes PR21015, and PR20993.                                                       
                                                                                  
Patch by Jun Koi


------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@222696 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-24 21:47:34 +00:00
Daniel Sanders
f47ab164df Merging r216262:
------------------------------------------------------------------------
r216262 | sstankovic | 2014-08-22 10:23:22 +0100 (Fri, 22 Aug 2014) | 5 lines

[mips] Don't use odd-numbered float registers for double arguments for fastcc
calling convention if FP is 64-bit and +nooddspreg is used.

Differential Revision: http://reviews.llvm.org/D4981.diff

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@222695 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-24 21:47:07 +00:00
Daniel Sanders
b164bc7bab Merging r221453:
------------------------------------------------------------------------
r221453 | tomatabacu | 2014-11-06 14:25:42 +0000 (Thu, 06 Nov 2014) | 17 lines

[mips] Tolerate the use of the %z inline asm operand modifier with non-immediates.

Summary:
Currently, we give an error if %z is used with non-immediates, instead of continuing as if the %z isn't there.

For example, you use the %z operand modifier along with the "Jr" constraints ("r" makes the operand a register, and "J" makes it an immediate, but only if its value is 0). 
In this case, you want the compiler to print "$0" if the inline asm input operand turns out to be an immediate zero and you want it to print the register containing the operand, if it's not.

We give an error in the latter case, and we shouldn't (GCC also doesn't).

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D6023
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@222693 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-24 21:42:40 +00:00
Daniel Sanders
5b34a189e1 Merging r221408:
------------------------------------------------------------------------
r221408 | petarj | 2014-11-05 22:42:31 +0000 (Wed, 05 Nov 2014) | 9 lines

[mips64] Fix MIPS64 exception personality encoding

Remove dynamic relocations of __gxx_personality_v0 from the .eh_frame.
The MIPS64 follow-up of the MIPS32 fix (rL209907).

Patch by Vladimir Stefanovic.

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

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@222692 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-24 21:37:42 +00:00
Daniel Sanders
fffc52d895 Merging r216920:
------------------------------------------------------------------------
r216920 | samsonov | 2014-09-02 18:49:16 +0100 (Tue, 02 Sep 2014) | 4 lines

Fix left shifts of negative values in MipsDisassembler.

This bug was reported by UBSan.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@222691 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-24 21:37:18 +00:00
Tom Stellard
78a5ffc665 Merging r220401:
------------------------------------------------------------------------
r220401 | mail | 2014-10-22 14:18:54 -0400 (Wed, 22 Oct 2014) | 6 lines

test: Make this test runnable in directories with @ in their names

Jenkins likes to use directories with names involving the '@'
character, which breaks the sed expression in this test. Switch to use
'|' on the assumption that it's less likely to show up in a path.

------------------------------------------------------------------------

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@221390 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-05 20:14:56 +00:00
Tom Stellard
7a882bdb36 Bump version to 3.5.1
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@220990 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-31 19:33:25 +00:00
Dan Liew
df820bfd87 Merging r217490:
------------------------------------------------------------------------
r217490 | delcypher | 2014-09-10 12:09:23 +0100 (Wed, 10 Sep 2014) | 4 lines

Don't attempt to run llvm-config in cmake/modules/Makefile when doing
``make clean`` because it won't be available.

This is an attempt to unbreak buildbots broken by r217484.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@217640 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-11 23:00:09 +00:00
Dan Liew
9f3db56ec8 Merging r217484:
------------------------------------------------------------------------
r217484 | delcypher | 2014-09-10 11:18:59 +0100 (Wed, 10 Sep 2014) | 13 lines

Attempt to fix PR20884

This fixes the generation of broken LLVMExports.cmake file by
the Autoconf/Makefile build system when --enable-shared is passed to
configure.

When --enable_shared is passed the Makefile.rules does not set the
LLVMConfigLibs variable which cmake/modules/Makefile previously relied
on. Now it runs the llvm-config command itself to get the library names.

This still isn't perfect because the generated LLVM targets refer to the
static libraries and not the shared library but that is much larger
problem to fix.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@217638 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-11 22:56:28 +00:00
Bill Wendling
830c9e0658 Update PowerPC target information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@217304 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-06 03:26:11 +00:00
Bill Wendling
f55c17bc33 Update release notes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@216951 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-02 21:22:28 +00:00
Bill Wendling
608c4d80d0 Update lang ref.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@216950 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-02 21:21:48 +00:00
Bill Wendling
1d7b9f52b5 Include blurb about Likely. By Josh Klontz.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@216762 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-29 20:00:59 +00:00
Bill Wendling
a62845035d Update to include ISPC. By Dmitry Babokin.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@216760 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-29 19:57:40 +00:00
Bill Wendling
a3313efbbe Merging r216064:
------------------------------------------------------------------------
r216064 | kongyi | 2014-08-20 03:40:20 -0700 (Wed, 20 Aug 2014) | 9 lines

ARM: Fix codegen for rbit intrinsic

LLVM generates illegal `rbit r0, #352` instruction for rbit intrinsic.
According to ARM ARM, rbit only takes register as argument, not immediate.
The correct instruction should be rbit <Rd>, <Rm>.

The bug was originally introduced in r211057.

Differential Revision: http://reviews.llvm.org/D4980
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@216089 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-20 17:42:35 +00:00
Bill Wendling
0883d3f4ea Merging r215711:
------------------------------------------------------------------------
r215711 | wschmidt | 2014-08-15 06:51:57 -0700 (Fri, 15 Aug 2014) | 8 lines

[PPC64] Add test case for r215685.

I had deferred adding this test case until I could get it down to a
reasonable size.  That's done now.

Thanks,
Bill

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@215879 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-18 05:16:58 +00:00
Bill Wendling
c806f89fda Merging r215685:
------------------------------------------------------------------------
r215685 | wschmidt | 2014-08-14 18:25:26 -0700 (Thu, 14 Aug 2014) | 69 lines

[PPC64] Add missing dependency on X2 to LDinto_toc.

The LDinto_toc pattern has been part of 64-bit PowerPC for a long
time, and represents loading from a memory location into the TOC
register (X2).  However, this pattern doesn't explicitly record that
it modifies that register.  This patch adds the missing dependency.

It was very surprising to me that this has never shown up as a problem
in the past, and that we only saw this problem recently in a single
scenario when building a self-hosted clang.  It turns out that in most
cases we have another dependency present that keeps the LDinto_toc
instruction tied in place.  LDinto_toc is used for TOC restore
following a call site, so this is a typical sequence:

   BCTRL8 <regmask>, %CTR8<imp-use>, %RM<imp-use>, %X3<imp-use>, %X12<imp-use>, %X1<imp-def>, ...
   LDinto_toc 24, %X1
   ADJCALLSTACKUP 96, 0, %R1<imp-def>, %R1<imp-use>

Because the LDinto_toc is inserted prior to the ADJCALLSTACKUP, there
is a natural anti-dependency between the two that keeps it in place.

Therefore we don't usually see a problem.  However, in one particular
case, one call is followed immediately by another call, and the second
call requires a parameter that is a TOC-relative address.  This is the
code sequence:

  BCTRL8 <regmask>, %CTR8<imp-use>, %RM<imp-use>, %X3<imp-use>, %X4<imp-use>, %X5<imp-use>, %X12<imp-use>, %X1<imp-def>, ...
  LDinto_toc 24, %X1
  ADJCALLSTACKUP 96, 0, %R1<imp-def>, %R1<imp-use>
  ADJCALLSTACKDOWN 96, %R1<imp-def>, %R1<imp-use>
  %vreg39<def> = ADDIStocHA %X2, <ga:@.str>; G8RC_and_G8RC_NOX0:%vreg39
  %vreg40<def> = ADDItocL %vreg39<kill>, <ga:@.str>; G8RC:%vreg40 G8RC_and_G8RC_NOX0:%vreg39

Note that the back-to-back stack adjustments are the same size!  The
back end is smart enough to recognize this and optimize them away:

  BCTRL8 <regmask>, %CTR8<imp-use>, %RM<imp-use>, %X3<imp-use>, %X4<imp-use>, %X5<imp-use>, %X12<imp-use>, %X1<imp-def>, ...
  LDinto_toc 24, %X1
  %vreg39<def> = ADDIStocHA %X2, <ga:@.str>; G8RC_and_G8RC_NOX0:%vreg39
  %vreg40<def> = ADDItocL %vreg39<kill>, <ga:@.str>; G8RC:%vreg40 G8RC_and_G8RC_NOX0:%vreg39

Now there is nothing to prevent the ADDIStocHA instruction from moving
ahead of the LDinto_toc instruction, and because of the longest-path
heuristic, this is what happens.

With the accompanying patch, %X2 is represented as an implicit def:

  BCTRL8 <regmask>, %CTR8<imp-use>, %RM<imp-use>, %X3<imp-use>, %X4<imp-use>, %X5<imp-use>, %X12<imp-use>, %X1<imp-def>, ...
  LDinto_toc 24, %X1, %X2<imp-def,dead>
  ADJCALLSTACKUP 96, 0, %R1<imp-def,dead>, %R1<imp-use>
  ADJCALLSTACKDOWN 96, %R1<imp-def,dead>, %R1<imp-use>
  %vreg39<def> = ADDIStocHA %X2, <ga:@.str>; G8RC_and_G8RC_NOX0:%vreg39
  %vreg40<def> = ADDItocL %vreg39<kill>, <ga:@.str>; G8RC:%vreg40 G8RC_and_G8RC_NOX0:%vreg39

So now when the two stack adjustments are removed, ADDIStocHA is
prevented from being moved above LDinto_toc.

I have not yet created a test case for this, because the original
failure occurs on a relatively large function that needs reduction.
However, this is a fairly serious bug, despite its infrequency, and I
wanted to get this patch onto the list as soon as possible so that it
can be considered for a 3.5 backport.  I'll work on whittling down a
test case.

Have we missed the boat for 3.5 at this point?

Thanks,
Bill

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@215878 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-18 05:16:33 +00:00
Bill Wendling
86518decf3 Merging r215806:
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@215874 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-18 05:14:39 +00:00
Bill Wendling
dd724a3652 Merging r214679:
------------------------------------------------------------------------
r214679 | chandlerc | 2014-08-03 17:54:28 -0700 (Sun, 03 Aug 2014) | 10 lines

[x86] Fix the test case added in r214670 and tweaked in r214674 further.

Fundamentally, there isn't a really portable way to test the constant
pool contents. Instead, pin this test to the bare-metal triple. This
also makes it a 64-bit triple which allows us to only match a single
constant pool rather than two. It can also just hard code the '.' prefix
as the format should be stable now that it has a fixed triple. Finally,
I've switched it to use CHECK-NEXT to be more precise in the instruction
sequence expected and to use variables rather than hard coding decisions
by the register allocator.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@215430 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-12 05:41:35 +00:00
Bill Wendling
e5c836ca22 Merging r214674:
------------------------------------------------------------------------
r214674 | spatel | 2014-08-03 16:20:16 -0700 (Sun, 03 Aug 2014) | 2 lines

Account for possible leading '.' in label string.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@215429 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-12 05:41:22 +00:00
Bill Wendling
70b7fc96d0 Merging r214670:
------------------------------------------------------------------------
r214670 | spatel | 2014-08-03 15:48:23 -0700 (Sun, 03 Aug 2014) | 8 lines

fix for PR20354 - Miscompile of fabs due to vectorization

This is intended to be the minimal change needed to fix PR20354 ( http://llvm.org/bugs/show_bug.cgi?id=20354 ). The check for a vector operation was wrong; we need to check that the fabs itself is not a vector operation.

This patch will not generate the optimal code. A constant pool load and 'and' op will be generated instead of just returning a value that we can calculate in advance (as we do for the scalar case). I've put a 'TODO' comment for that here and expect to have that patch ready soon.

There is a very similar optimization that we can do in visitFNEG, so I've put another 'TODO' there and expect to have another patch for that too.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@215428 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-12 05:41:11 +00:00
Bill Wendling
5dddab4cb5 Revert r.215058.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@215426 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-12 05:35:26 +00:00
Pekka Jaaskelainen
7c5a09c798 Added pocl and TCE to the list of projects that work with Clang/LLVM 3.5.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@215090 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-07 09:06:53 +00:00
Bill Wendling
248aeb959b Merging r214481:
------------------------------------------------------------------------
r214481 | hfinkel | 2014-07-31 22:20:41 -0700 (Thu, 31 Jul 2014) | 38 lines

[PowerPC] Generate unaligned vector loads using intrinsics instead of regular loads

Altivec vector loads on PowerPC have an interesting property: They always load
from an aligned address (by rounding down the address actually provided if
necessary). In order to generate an actual unaligned load, you can generate two
load instructions, one with the original address, one offset by one vector
length, and use a special permutation to extract the bytes desired.

When this was originally implemented, I generated these two loads using regular
ISD::LOAD nodes, now marked as aligned. Unfortunately, there is a problem with
this:

The alignment of a load does not contribute to its identity, and SDNodes
are uniqued. So, imagine that we have some unaligned load, L1, that is not
aligned. The routine will create two loads, L1(aligned) and (L1+16)(aligned).
Further imagine that there had already existed a load (L1+16)(unaligned) with
the same chain operand as the load L1. When (L1+16)(aligned) is created as part
of the lowering of L1, this load *is* also the (L1+16)(unaligned) node, just
now marked as aligned (because the new alignment overwrites the old). But the
original users of (L1+16)(unaligned) now get the data intended for the
permutation yielding the data for L1, and (L1+16)(unaligned) no longer exists
to get its own permutation-based expansion. This was PR19991.

A second potential problem has to do with the MMOs on these loads, which can be
used by AA during instruction scheduling to break chain-based dependencies. If
the new "aligned" loads get the MMO from the original unaligned load, this does
not represent the fact that it will load data from below the original address.
Normally, this would not matter, but this load might be combined with another
load pair for a previous vector, and then the dependency on the otherwise-
ignored lower bytes can matter.

To fix both problems, instead of generating the necessary loads using regular
ISD::LOAD instructions, ppc_altivec_lvx intrinsics are used instead. These are
provided with MMOs with a conservative address range.

Unfortunately, I no longer have a failing test case (since PR19991 was
reported, other changes in CodeGen have forced this bug back into hiding it
again). Nevertheless, this should fix the underlying problem.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@215058 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-07 04:52:45 +00:00
Bill Wendling
f8c84d2889 Revert renaming. Should rename tags instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@215011 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-06 23:15:25 +00:00
Bill Wendling
7892e5686d Renaming to coincide with updated tagging system.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_350@215001 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-06 23:13:41 +00:00
Bill Schmidt
fa840e7dfb Correct faulty merge of r214923 due to echristo's subversion changes in trunk
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214927 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-05 21:15:38 +00:00
Bill Schmidt
e342c688a1 Merging r214923:
------------------------------------------------------------------------
r214923 | wschmidt | 2014-08-05 15:47:25 -0500 (Tue, 05 Aug 2014) | 12 lines

[PowerPC] Swap arguments and adjust shift count for vsldoi on little endian

Commits r213915 and r214718 fix recognition of shuffle masks for vmrg*
and vpku*um instructions for a little-endian target, by swapping the
input arguments.  The vsldoi instruction requires similar treatment,
and also needs its shift count adjusted for little endian.

Reviewed by Ulrich Weigand.

This is a bug fix candidate for release 3.5 (and hopefully the last of
those for PowerPC).

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214926 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-05 20:59:06 +00:00
Tom Stellard
97fd0f6a14 Merging r214865:
------------------------------------------------------------------------
r214865 | thomas.stellard | 2014-08-05 10:40:52 -0400 (Tue, 05 Aug 2014) | 5 lines

R600/SI: Avoid generating REGISTER_LOAD instructions.

SI doesn't use REGISTER_LOAD anymore, but it was still hitting this code
path for 8-bit and 16-bit private loads.

------------------------------------------------------------------------

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214895 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-05 17:38:25 +00:00
Tom Stellard
cd4bff761f Merging r214463:
------------------------------------------------------------------------
r214463 | thomas.stellard | 2014-07-31 20:32:28 -0400 (Thu, 31 Jul 2014) | 7 lines

R600/SI: Fix incorrect commute operation in shrink instructions pass

We were commuting the instruction by still shrinking it using the
original opcode.

NOTE: This is a candidate for the 3.5 branch.

------------------------------------------------------------------------

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214894 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-05 17:38:23 +00:00
Bill Wendling
aaca7cbad6 Add blurb about LDC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214842 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-05 05:23:26 +00:00
Bill Wendling
169c2e7a89 Merging r213799:
------------------------------------------------------------------------
r213799 | grosbach | 2014-07-23 13:41:38 -0700 (Wed, 23 Jul 2014) | 5 lines

X86: restrict combine to when type sizes are safe.

The folding of unary operations through a vector compare and mask operation
is only safe if the unary operation result is of the same size as its input.
For example, it's not safe for [su]itofp from v4i32 to v4f64.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214841 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-05 05:20:22 +00:00
Bill Schmidt
81e74bc0ca Fix incorrectly resolved merge conflict
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214822 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-04 23:47:21 +00:00
Bill Schmidt
710e7192ab Merging r214800:
------------------------------------------------------------------------
r214800 | wschmidt | 2014-08-04 18:21:01 -0500 (Mon, 04 Aug 2014) | 13 lines

[PPC64LE] Fix wrong IR for vec_sld and vec_vsldoi

My original LE implementation of the vsldoi instruction, with its
altivec.h interfaces vec_sld and vec_vsldoi, produces incorrect
shufflevector operations in the LLVM IR.  Correct code is generated
because the back end handles the incorrect shufflevector in a
consistent manner.

This patch and a companion patch for Clang correct this problem by
removing the fixup from altivec.h and the corresponding fixup from the
PowerPC back end.  Several test cases are also modified to reflect the
now-correct LLVM IR.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214821 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-04 23:44:59 +00:00
Bill Schmidt
2f02380b9b Merging r214721:
------------------------------------------------------------------------
r214721 | uweigand | 2014-08-04 09:55:26 -0500 (Mon, 04 Aug 2014) | 4 lines

[PowerPC] Add target triple to vec_urem_const.ll test case

This should hopefully fix build bots on other architectures.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214820 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-04 23:43:34 +00:00
Bill Schmidt
b777868f63 Merging r214718:
------------------------------------------------------------------------
r214718 | uweigand | 2014-08-04 08:53:40 -0500 (Mon, 04 Aug 2014) | 12 lines

[PowerPC] Swap arguments to vpkuhum/vpkuwum on little-endian

In commit r213915, Bill fixed little-endian usage of vmrgh* and vmrgl*
by swapping the input arguments.  As it turns out, the exact same fix
is also required for the vpkuhum/vpkuwum patterns.

This fixes another regression in llvmpipe when vector support is
enabled.

Reviewed by Bill Schmidt.


------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214819 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-04 23:42:09 +00:00
Bill Schmidt
c5ca284e85 Merging r214716:
------------------------------------------------------------------------
r214716 | uweigand | 2014-08-04 08:27:12 -0500 (Mon, 04 Aug 2014) | 9 lines

[PowerPC] MULHU/MULHS are not legal for vector types

I ran into some test failures where common code changed vector division
by constant into a multiply-high operation (MULHU).  But these are not
implemented by the back-end, so we failed to recognize the insn.

Fixed by marking MULHU/MULHS as Expand for vector types.


------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214818 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-04 23:41:27 +00:00
Bill Schmidt
39f807fc9f Merging r214714:
------------------------------------------------------------------------
r214714 | uweigand | 2014-08-04 08:13:57 -0500 (Mon, 04 Aug 2014) | 19 lines

[PowerPC] Fix and improve vector comparisons

This patch refactors code generation of vector comparisons.

This fixes a wrong code-gen bug for ISD::SETGE for floating-point types,
and improves generated code for vector comparisons in general.

Specifically, the patch moves all logic deciding how to implement vector
comparisons into getVCmpInst, which gets two extra boolean outputs
indicating to its caller whether its needs to swap the input operands
and/or negate the result of the comparison.  Apart from implementing
these two modifications as directed by getVCmpInst, there is no need
to ever implement vector comparisons in any other manner; in particular,
there is never a need to perform two separate comparisons (e.g. one for
equal and one for greater-than, as code used to do before this patch).

Reviewed by Bill Schmidt.


------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214817 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-04 23:37:33 +00:00
Bill Wendling
ea5288432e Merging r214060:
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214764 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-04 19:58:16 +00:00
Bill Wendling
6b61604359 Merging r213966:
------------------------------------------------------------------------
r213966 | brad | 2014-07-25 12:28:44 -0700 (Fri, 25 Jul 2014) | 4 lines

Fix arc4random detection.

Patch by Pascal Stumpf.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214749 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-04 18:36:56 +00:00
Bill Wendling
24b7c34200 Merging r213999:
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214747 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-04 18:35:56 +00:00
Bill Wendling
7f154753ce Merging r213665:
------------------------------------------------------------------------
r213665 | tnorthover | 2014-07-22 08:47:09 -0700 (Tue, 22 Jul 2014) | 11 lines

X86: drop relocations on __eh_frame sections globally.

Without this, we produce non-extern relocations when targeting older OS X
versions that ld64 can't cope with in the particular context of __eh_frame
sections (who'd want generic relocation-processing anyway?).

This means that an updated linker (ld64 from Xcode 3.2.6 or later) may be
needed when targeting such platforms with a modern version of LLVM, but this is
probably the case anyway and a reasonable requirement.

PR20212, rdar://problem/17544795
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214689 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-04 04:29:47 +00:00
Bill Wendling
92a10767eb Merging r213726:
------------------------------------------------------------------------
r213726 | nicholas | 2014-07-22 23:24:49 -0700 (Tue, 22 Jul 2014) | 2 lines

We may visit a call that uses an alloca multiple times in callUsesLocalStack, sometimes with IsNocapture true and sometimes with IsNocapture false. We accidentally skipped work we needed to do in the IsNocapture=false case if we were called with IsNocapture=true the first time. Fixes PR20405!

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214688 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-04 04:28:45 +00:00