They are equivalent and the size of 'a' and 's' is unused.

llvm-svn: 197259

llvm-svn: 197255

llvm-svn: 197254

llvm-svn: 197253

step, floating-point reciprocal square root step, floating-point absolute
difference, and integer/floating-point compare instructions.  Also, move the
scalar general arithmetic operation patterns closer to similar code.  No
functional change intended.

llvm-svn: 197250

llvm-svn: 197249

The cpp backend is not a reasonable fallback for a missing target. It is a
very special backend, so it is reasonable to use it only if explicitly
requested.

While at it, simplify the interface a bit.

llvm-svn: 197241

In those cases it's better to compare the result of the subtraction
against zero.

llvm-svn: 197239

This originally came about after noticing that InstCombine turns
some of the TMHH (icmp (and...), ...) tests into plain comparisons.
Since there is no instruction to compare with a 64-bit immediate,
TMHH is generally better than an ordered comparison for the cases
that it can handle.

llvm-svn: 197238

Amend a comment.

llvm-svn: 197237

This patch makes more use of LPGFR and LNGFR.  It builds on top of
the LTGFR selection from r197234.  Most of the tests are motivated
by what InstCombine would produce.

llvm-svn: 197236

...in an attempt to rein back the increasingly complex selection code.
A knock-on effect is that ICmpType is exposed from the outset, which
slightly simplifies adjustSubwordCmp.

The code is no piece of art even after this change, but at least it should
be slightly better.  No behavioral change intended.

llvm-svn: 197235

InstCombine turns (sext (trunc)) into (ashr (shl)), then converts any
comparison of the ashr against zero into a comparison of the shl against zero.
This makes sense in itself, but we want to undo it for z, since the sign-
extension instruction has a CC-setting form.

I've included tests for both the original and InstCombined variants,
but the former already worked.  The patch fixes the latter.

llvm-svn: 197234

While it's safe for the X86-specific shift nodes, dag combining will
kill generic nodes. Insert an AND to make it safe, isel will nuke it
as x86's shift instructions have an implicit AND.

Fixes PR16108, which contains a contraption to hit this case in between
constant folders.

llvm-svn: 197228

with a temporary assertion and adjust the various test cases.

llvm-svn: 197224

branch instructions for mips and micromips instruction sets thus avoiding
the situation of generating branches to undesired locations if offsets
cannot be encoded.

This patch also checks if a fixup cannot be applied and returns a fatal error
if that's the case.

llvm-svn: 197223

llvm-svn: 197220

through an invoke instruction.

The original patch for this was written by Mark Seaborn, but I've
reworked his test case into the existing returns_twice test case and
implemented the fix by the prior refactoring to actually run the cost
analysis over invoke instructions, and then here fixing our detection of
the returns_twice attribute to work for both calls and invokes. We never
noticed because we never saw an invoke. =[

llvm-svn: 197216

handles terminator instructions.

The inline cost analysis inheritted some pretty rough handling of
terminator insts from the original cost analysis, and then made it much,
much worse by factoring all of the important analyses into a separate
instruction visitor. That instruction visitor never visited the
terminator.

This works fine for things like conditional branches, but for many other
things we simply computed The Wrong Value. First example are
unconditional branches, which should be free but were counted as full
cost. This is most significant for conditional branches where the
condition simplifies and folds during inlining. We paid a 1 instruction
tax on every branch in a straight line specialized path. =[

Oh, we also claimed that the unreachable instruction had cost.

But it gets worse. Let's consider invoke. We never applied the call
penalty. We never accounted for the cost of the arguments. Nope. Worse
still, we didn't handle the *correctness* constraints of not inlining
recursive invokes, or exception throwing returns_twice functions. Oops.
See PR18206. Sadly, PR18206 requires yet another fix, but this
refactoring is at least a huge step in that direction.

llvm-svn: 197215

Revert "DebugInfo: Move type units into the debug_types section with appropriate comdat grouping and type unit headers"

This reverts commit r197210.

llvm-svn: 197211

DebugInfo: Move type units into the debug_types section with appropriate comdat grouping and type unit headers

This commit does not complete the type units feature - there are issues
around fission support (skeletal type units, pubtypes/pubnames) and
hashing of some types including those containing references to types in
other type units.

Originally committed as r197073 and reverted in r197079.
Recommitted as r197197 to reproduce the failure and reverted as r197199

Turns out there was unstable ordering in the type unit dumping code.
Fixed by using MapVector in DWARFContext to store the debug_types
comdat sections.

llvm-svn: 197210

Since gcc 4.6 the compiler uses ___chkstk_ms which has the same semantics as the
MS CRT function __chkstk. This simplifies the prologue generation a bit.

Reviewed by Rafael Espíndola. 

llvm-svn: 197205

The previous definition was wrong. See Microsoft PE/COFF specification
section 5.3.2.

llvm-svn: 197204

Revert "DebugInfo: Move type units into the debug_types section with appropriate comdat grouping and type unit headers"

This reverts commit r197197.

llvm-svn: 197199

This option tells llvm-cov to print out branch probabilities when
a basic block contains multiple branches. It also prints out some
function summary info including the number of times the function enters,
the percent of time it returns, and how many blocks were executed.

Also updated tests.

llvm-svn: 197198

DebugInfo: Move type units into the debug_types section with appropriate comdat grouping and type unit headers

This commit does not complete the type units feature - there are issues
around fission support (skeletal type units, pubtypes/pubnames) and
hashing of some types including those containing references to types in
other type units.

Originally committed as r197073 and reverted in r197079.

This commit originally got jumbled up with another build-breaking commit
and I can't find the failures I thought this caused anymore.
Recommitting to hopefully get some clean buildbot results to work from.
I have a sneaking suspicion there's unstable output in the comdat group
output of MCStreamer...

llvm-svn: 197197

llvm-svn: 197180

GlobalOpt's CleanupConstantGlobalUsers function uses a worklist array to manage
constant users to be visited. The pointers in this array need to be weak
handles because when we delete a constant array, we may also be holding a
pointer to one of its elements (or an element of one of its elements if we're
dealing with an array of arrays) in the worklist.

Fixes PR17347.

llvm-svn: 197178

The barrier pass is a temporary hack, and should go away soon. Nevertheless, if
we don't initialize it, then opt will not understand -barrier, and this will
break bugpoint (because when it dumps the passes from the default pass manager
-barrier will be there).

llvm-svn: 197177

More comprehensive llvm-cov tests were added to tools/llvm-cov.

llvm-svn: 197175

No functionality change.

Reviewed by Tim Northover.

llvm-svn: 197172

Reviewed by Richard Sandiford.

llvm-svn: 197170

It means exactly the same and is just a bit shorter.

llvm-svn: 197169

llvm-svn: 197168

llvm-svn: 197166

GCC 4.7 changed the MingW ABI. On the LLVM side it means that sret functions
don't pop the stack.

llvm-svn: 197163

- Copy patterns with float/double types are enough.
- Fix typos in test case names that were using v1fx.
- There is no ACLE intrinsic that uses v1f32 type.  And there is no conflict of
  neon and non-neon ovelapped operations with this type, so there is no need to
  support operations with this type.
- Remove v1f32 from FPR32 register and disallow v1f32 as a legal type for
  operations.

Patch by Ana Pazos!

llvm-svn: 197159

llvm-svn: 197158

llvm-svn: 197149

The tests were failing on OS X.

llvm-svn: 197146