Hard float for mips16 means essentially to compile as soft float but to
use a runtime library for soft float that is written with native mips32
floating point instructions (those runtime routines run in mips32 hard
float mode).

The patch reviewed by Reed Kotler.

llvm-svn: 195123

llvm-svn: 195122

llvm-svn: 195121

we can emit various sections in any order.
No functional change.

llvm-svn: 195120

llvm-svn: 195119

order of slices of the alloca which have exactly the same size and other
properties. This was found by a perniciously unstable sort
implementation used to flush out buggy uses of the algorithm.

The fundamental idea is that findCommonType should return the best
common type it can find across all of the slices in the range. There
were two bugs here previously:

1) We would accept an integer type smaller than a byte-width multiple,
   and if there were different bit-width integer types, we would accept
   the first one. This caused an actual failure in the testcase updated
   here when the sort order changed.
2) If we found a bad combination of types or a non-load, non-store use
   before an integer typed load or store we would bail, but if we found
   the integere typed load or store, we would use it. The correct
   behavior is to always use an integer typed operation which covers the
   partition if one exists.

While a clever debugging sort algorithm found problem #1 in our existing
test cases, I have no useful test case ideas for #2. I spotted in by
inspection when looking at this code.

llvm-svn: 195118

Patch by Dmitri Shtilman!

llvm-svn: 195116

llvm-svn: 195103

llvm-svn: 195102

A column limit in the test folder can lead to trouble as the RUN, CHECK,
etc. comments can potentially be broken over multiple lines changing
their meaning. Without column limit, clang-format will simply keep the
test author's line breaks.

llvm-svn: 195100

Fixes <rdar://15487687> [JS] AnyRegCC argument ends up being spilled

llvm-svn: 195094

Hard-coded operand indices were scattered throughout lowering stages
and layers. It was super bug prone.

llvm-svn: 195093

This patch places class definitions in implementation files into anonymous
namespaces to prevent weak vtables. This eliminates the need of providing an
out-of-line definition to pin the vtable explicitly to the file.

llvm-svn: 195092

llvm-svn: 195078

llvm-svn: 195077

llvm-svn: 195076

llvm-svn: 195075

llvm-svn: 195074

llvm-svn: 195072

llvm-svn: 195071

No true functional changes.

Change the "hack" name of emitMipsHackSTOCG to emitSymSTO.

Remove demonstration code in AsmParser for emitMipsHackSTOCG and
emitMipsHackELFFlags. The STO field is in an ELF symbol and is not
an explicit directive. That said, we are missing the compliment call
in AsmParser and that will need to be addressed soon.

XFAIL dummy tests for emitMipsHackELFFlags and emitMipsHackELFFlags.
These will built out with following patches.

llvm-svn: 195067

This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file. The memory leaks in this version have been fixed. Thanks
Alexey for pointing them out.

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

Reviewed by Andy

llvm-svn: 195064

llvm-svn: 195063

llvm-svn: 195060

llvm-svn: 195059

No functionality changes.

llvm-svn: 195057

DebugInfo: Simplify a few more explicit constructions, underconstrained types, and make DIType(MDNode*) explicit like all the other DI* node ctors.

llvm-svn: 195055

This reverts commit r190888, to fix PR17967.  The original change wasn't
the right way to get @feat.00 into the object file.  The right fix is to
make @feat.00 be a global symbol.

llvm-svn: 195053

lowering only for load/stores to scalar allocas. The resulting values
confuse the backend and don't add anything because we can describe
array-allocas with a dbg.declare intrinsic just fine.

rdar://problem/15464571

llvm-svn: 195052

llvm-svn: 195049

(except functions marked always_inline).
Functions with 'optnone' must also have 'noinline' so they don't get
inlined into any other function.

Based on work by Andrea Di Biagio.

llvm-svn: 195046

Moving into a VSrc doesn't always work, since it could be
replaced with an SGPR later.

llvm-svn: 195042

No other SGPR operands are allowed, so if VCC is
used, move the other to a VGPR.

llvm-svn: 195041

Test doesn't actually check the output. I need
to fix add i64 being matched for the addressing
calculations.

llvm-svn: 195040

llvm-svn: 195039

llvm-svn: 195038

The carry always goes to SCC.

llvm-svn: 195037

llvm-svn: 195036

llvm-svn: 195035

llvm-svn: 195034