Revert "Revert "[APFloat] Removed APFloat constructor which initialized to either zero/NaN but allowed you to arbitrarily set the category of the float.""

This reverts commit r185099.

Looks like both the ppc-64 and mips bots are still failing after I reverted this
change.

Since:

1. The mips bot always performs a clean build,
2. The ppc64-bot failed again after a clean build (I asked the ppc-64
maintainers to clean the bot which they did... Thanks Will!),

I think it is safe to assume that this change was not the cause of the failures
that said builders were seeing. Thus I am recomitting.

llvm-svn: 185111

This reverts commit r184817. The failure Chandler was seeing was most likely the
bug that Bob Wilson fixed in r184870 (which was a bug caught by these tests).

To be safe, I just checked again on x86-64 mac os x/linux that this test passed
(which it did).

llvm-svn: 185110

its only caller with a FIXME explaining why it's bogus.

llvm-svn: 185109

llvm-svn: 185108

Both StopReadThread and the thread being stopped set the thread id to
0 after m_read_thread_enabled was set to false. If the thread being
stopped got there first then StopReadThread called pthread_join on an
invalid thread number. This is not a Good Thing,

Should fix a fairly regular segfault when quitting on Linux.

llvm-svn: 185107

llvm-svn: 185106

llvm-svn: 185105

llvm-svn: 185104

llvm-svn: 185103

llvm-svn: 185102

llvm-svn: 185101

Under -fms-extensions, only inject a friend tag name when we didn't see a tag with that name in an enclosing scope.

r177473 made us correctly consider only those declarations in the
enclosing namespace scope when looking for a friend declaration. Under
ms-extensions mode, where we do some level of friend injection, this
meant that we were introducing a new tag type into a different scope
than what Microsoft actually does. Address this by only doing the
friend injection when we didn't see any tag with that name in any
outer scope. Fixes <rdar://problem/14250378>.

llvm-svn: 185100

Revert "[APFloat] Removed APFloat constructor which initialized to either zero/NaN but allowed you to arbitrarily set the category of the float."

This reverts commit r185095. This is causing a FileCheck failure on
the 3dnow intrinsics on at least the mips/ppc bots but not on the x86
bots.

Reverting while I figure out what is going on.

llvm-svn: 185099

llvm-svn: 185098

Otherwise, we end up with an exponential IR blowup.
Fixes PR16472.

llvm-svn: 185097

llvm-svn: 185096

[APFloat] Removed APFloat constructor which initialized to either zero/NaN but allowed you to arbitrarily set the category of the float.

The category which an APFloat belongs to should be dependent on the
actual value that the APFloat has, not be arbitrarily passed in by the
user. This will prevent inconsistency bugs where the category and the
actual value in APFloat differ.

I also fixed up all of the references to this constructor (which were
only in LLVM).

llvm-svn: 185095

algorithm when assigning EnumValues to the synthesized registers.

The current algorithm, LessRecord, uses the StringRef compare_numeric
function.  This function compares strings, while handling embedded numbers.
For example, the R600 backend registers are sorted as follows:

  T1
  T1_W
  T1_X
  T1_XYZW
  T1_Y
  T1_Z
  T2
  T2_W
  T2_X
  T2_XYZW
  T2_Y
  T2_Z

In this example, the 'scaling factor' is dEnum/dN = 6 because T0, T1, T2
have an EnumValue offset of 6 from one another.  However, in other parts
of the register bank, the scaling factors are different:

dEnum/dN = 5:
  KC0_128_W
  KC0_128_X
  KC0_128_XYZW
  KC0_128_Y
  KC0_128_Z
  KC0_129_W
  KC0_129_X
  KC0_129_XYZW
  KC0_129_Y
  KC0_129_Z

The diff lists do not work correctly because different kinds of registers have
different 'scaling factors'.  This new algorithm, LessRecordRegister, tries to
enforce a scaling factor of 1.  For example, the registers are now sorted as
follows:

  T1
  T2
  T3
  ...
  T0_W
  T1_W
  T2_W
  ...
  T0_X
  T1_X
  T2_X
  ...
  KC0_128_W
  KC0_129_W
  KC0_130_W
  ...

For the Mips and R600 I see a 19% and 6% reduction in size, respectively.  I
did see a few small regressions, but the differences were on the order of a
few bytes (e.g., AArch64 was 16 bytes).  I suspect there will be even
greater wins for targets with larger register files.

Patch reviewed by Jakob.
rdar://14006013

llvm-svn: 185094

llvm-svn: 185093

llvm-svn: 185092

* Use a single stat to find out if the file exists and if it is a regular file.
* Use early returns when possible.
* Add comments explaining why we have each check.

llvm-svn: 185091

llvm-svn: 185089

the time when the IRInterpreter ran inside
IRForTarget.

llvm-svn: 185088

Because Registry.h is using the LLVM_DELETED_FUNCTION macro.

llvm-svn: 185087

llvm-svn: 185086

CostModel: improve the cost model for load/store of non power-of-two types such as <3 x float>, which are popular in graphics.

llvm-svn: 185085

The purpose of this test was to check boundary conditions for the size
of an ALU clause.  This test is very sensitive to changes to the
optimizer or scheduler, because it requires an exact number of ALU
instructions in order to remain valid.  It's not good to have a test
this sensitive, because it is confusing to developers who implement
optimizations and then 'break' the test.

I'm not sure if there is a good way to test these limits using lit, but
if I can come up with replacement test that isn't as sensitive I'll add
it back to the tree.

llvm-svn: 185084

llvm-svn: 185082

Use vectorized instruction instead of original instruction anchored in the
original loop.

Fixes PR16452 and t2075.c of PR16455.

llvm-svn: 185081

It fixes PR16338 (ICE when compiling very large two-dimensional array).

Differential Revision: http://llvm-reviews.chandlerc.com/D1043

llvm-svn: 185080

llvm-svn: 185079

full proper list of dynamic symbols crashes old gold (see bug 16468).
the culprit is 'memcpy' function, if it's added to syms file, gold crashes

llvm-svn: 185078

llvm-svn: 185077

llvm-svn: 185076

llvm-svn: 185075

llvm-svn: 185073

llvm-svn: 185072

llvm-svn: 185071

llvm-svn: 185070

llvm-svn: 185069