This patch introduces RegisterOperand class into Mips FPU instruction definitions and adds dedicated parser methods to MipsAsmParser. It is the first in a series of patches that should fix the problems with parsing Mips FPU instructions and optimize the code in MipsAsmParser.

llvm-svn: 184716

llvm-svn: 184715

[APFloat] Added a large unittest for APFloat.add that checks that special values are computed correctly.

llvm-svn: 184714

llvm-svn: 184713

llvm-svn: 184712

[APFloat] Removed a assert from significandParts() which says that one can only access the significand of FiniteNonZero/NaN floats.

The method significandParts() is a helper method meant to ease access to
APFloat's significand by allowing the user to not need to be aware of whether or
not the APFloat is using memory allocated in the instance itself or in an
external array.

This assert says that one can only access the significand of FiniteNonZero/NaN
floats. This makes it cumbersome and more importantly dangerous when one wishes
to zero out the significand of a zero/infinity value since one will have to deal
with the aforementioned quandary related to how the memory in APFloat is
allocated.

llvm-svn: 184711

[APFloat] Rename macro convolve => PackCategoriesIntoKey so that it is clear what APFloat is actually using said macro for.

In the context of APFloat, seeing a macro called convolve suggests that APFloat
is using said value in some sort of convolution somewhere in the source code.
This is misleading.

I also added a documentation comment to the macro.

llvm-svn: 184710

llvm-svn: 184709

atexit.

llvm-svn: 184708

When encoded to thumb, VFP instruction and VMOV/VDUP between scalar and
core registers, must have their predicate bit to 0b1110.

llvm-svn: 184707

llvm-svn: 184706

Sorry for the unit test churn. I'll try to make the change permanently
next time.

llvm-svn: 184705

llvm-svn: 184704

In thumb1, NOP is a pseudo-instruction equivalent to mov r8, r8.
However the disassembler should not use this alias.

llvm-svn: 184703

mask == 0 -> UNPRED

llvm-svn: 184702

llvm-svn: 184701

Also clean up LSan code, fix some comments and replace void* with uptr
to bring down the number of reinterpret_casts.

llvm-svn: 184700

llvm-svn: 184699

CGSCC pass manager. This should insulate the inlining decisions from the
vectorization decisions, however it may have both compile time and code
size problems so it is just an experimental option right now.

Adding this based on a discussion with Arnold and it seems at least
worth having this flag for us to both run some experiments to see if
this strategy is workable. It may solve some of the regressions seen
with the loop vectorizer.

llvm-svn: 184698

There is some hope of eventually supporting a unified build with it, but
until then this lets me (and others) check it out in this location
without things breaking.

llvm-svn: 184697

constructing a lookup table.

Previously, buildLookup would add lookup table entries for each item lexically
within the DC, and adding the first entry with a given name would trigger the
external source to add all its entries with that name. Then buildLookup would
carry on and re-add those entries all over again.

Instead, follow a simple rule: a declaration from an external source is only
ever made visible by the external source. One exception to this: since we don't
usually build a lookup table for the TU in C, and we never serialize one, we
don't expect the external source to provide lookups in the TU in C, so we build
those ones ourselves.

llvm-svn: 184696

There's still a problem here - since we're not appropriately using the
signedness/range of the enum to chooset the encoding and emission of
enumerators, but GCC has some bugs around this too so I assume that's
not /such/ a high priority though I may get to it soon out of
completeness.

llvm-svn: 184695

llvm-svn: 184694

The assembly generation testing has been moved to an LLVM test case.

llvm-svn: 184693

llvm-svn: 184692

llvm-svn: 184691

This reverts commit cbfa1ca993363ca5c4dbf6c913abc957c584cbac.

We are seeing a stage2 and stage3 miscompare on some dragonegg bots.

llvm-svn: 184690

llvm-svn: 184689

Original patch by Fariborz Jahanian; extended by me.

Fixes rdar://14124644

llvm-svn: 184688

I already finished the isIEEENormal => isNormal transition. So isNormal is now
IEEE-754R compliant.

llvm-svn: 184687

exponent_t is only used internally in APFloat and no exponent_t values are
exposed via the APFloat API. In light of such conditions it does not make any
sense to gum up the llvm namespace with said type. Plus it makes it clearer that
exponent_t is associated with APFloat.

llvm-svn: 184686

We now no longer need alias analysis - the cases that alias analysis would
handle are now handled as accesses with a large dependence distance.

We can now vectorize loops with simple constant dependence distances.

  for (i = 8; i < 256; ++i) {
    a[i] = a[i+4] * a[i+8];
  }

  for (i = 8; i < 256; ++i) {
    a[i] = a[i-4] * a[i-8];
  }

We would be able to vectorize about 200 more loops (in many cases the cost model
instructs us no to) in the test suite now. Results on x86-64 are a wash.

I have seen one degradation in ammp. Interestingly, the function in which we
now vectorize a loop is never executed so we probably see some instruction
cache effects. There is a 2% improvement in h264ref. There is one or the other
TSCV loop kernel that speeds up.

radar://13681598

llvm-svn: 184685

This class checks dependences by subtracting two Scalar Evolution access
functions allowing us to catch very simple linear dependences.

The checker assumes source order in determining whether vectorization is safe.
We currently don't reorder accesses.
Positive true dependencies need to be a multiple of VF otherwise we impede
store-load forwarding.

llvm-svn: 184684

Sets of dependent accesses are built by unioning sets based on underlying
objects. This class will be used by the upcoming dependence checker.

llvm-svn: 184683

This renames variable name to reflect initial undefined symbols that are
defined by the linker -u option.

This doesnot change any functionality in lld, and updates code to reflect
Nick's comment.

llvm-svn: 184682

Untill now we detected the vectorizable tree and evaluated the cost of the
entire tree.  With this patch we can decide to trim-out branches of the tree
that are not profitable to vectorizer.

Also, increase the max depth from 6 to 12. In the worse possible case where all
of the code is made of diamond-shaped graph this can bring the cost to 2**10,
but diamonds are not very common.

llvm-svn: 184681

This makes it possible to write unit tests that are less susceptible
to minor code motion, particularly copy placement. block-placement.ll
covers this case with -pre-RA-sched=source which will soon be
default. One incorrectly named block is already fixed, but without
this fix, enabling new coalescing and scheduling would cause more
failures.

llvm-svn: 184680

whether they replace any existing lookups in the context, rather than
accumulating a bunch of lookup results referring to the same entity.

llvm-svn: 184679

follow.

llvm-svn: 184678

llvm-svn: 184677