The problem of r191017 is that when GVN fabricate a val-number for a dead instruction (in order
to make following expr-PRE happy), it forget to fabricate a leader-table entry for it as well.

llvm-svn: 191118

Clean up some simple code quality issues. Bring internal naming
conventions up to current standard, fix inconsistent formatting, and
tidy up a couple of odd contructs.

llvm-svn: 191117

to further work.

llvm-svn: 191113

llvm-svn: 191112

Patch by Dimitry Andric

llvm-svn: 191111

I cannot think of a test case that reliably triggers this bug.

llvm-svn: 191109

Match reductions starting at binary operation feeding into a phi. The code
handles trees like

 r += v1 + v2 + v3 ...

and

 r += v1
 r += v2
 ...

and

 r *= v1 + v2 + ...

We currently only handle associative operations (add, fadd fast).

The code can now also handle reductions feeding into stores.

 a[i] = v1 + v2 + v3 + ...

The code is currently disabled behind the flag "-slp-vectorize-hor".  The cost
model for most architectures is not there yet.

I found one opportunity of a horizontal reduction feeding a phi in TSVC
(LoopRerolling-flt) and there are several opportunities where reductions feed
into stores.

radar://14607682

llvm-svn: 191108

llvm-svn: 191105

llvm-svn: 191104

--gtest_filter was filtering an invalid name for the test.

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

llvm-svn: 191100

The GEP pattern is what SCEV expander emits for "ugly geps". The latter is what
you get for pointer subtraction in C code. The rest of instcombine already
knows how to deal with that so just canonicalize on that.

llvm-svn: 191090

llvm-svn: 191088

llvm-svn: 191087

llvm-svn: 191086

llvm-svn: 191082

This reverts r191030

llvm-svn: 191075

llvm-svn: 191073

The global registry is used to allow command line override of the
scheduler selection, but does not work well as the normal selection
API. For example, the same LLVM process should be able to target
multiple targets or subtargets.

llvm-svn: 191071

llvm-svn: 191065

llvm-svn: 191062

DebugInfo: GDBIndexEntry*String conversion functions now return const char* for easy llvm::formating

This was previously invoking UB by passing a user-defined type to
format. Thanks to Jordan Rose for pointing this out.

llvm-svn: 191060

These violations were introduced in r191049

llvm-svn: 191059

Ensures that the pubnames entries actually refer to the intended
entities. This test could be more flexible if there was a way to do
multiline FileCheck matches with captures (in that way the test wouldn't
need to have hardcoded offset values and would thus be resilient to
changes in the layout of the DIEs in this CU).

llvm-svn: 191055

llvm-svn: 191053

llvm-svn: 191052

This was an experimental scheduler a year ago. It's now used by
several subtargets, both in-order and out-of-order, and it
is about to be enabled by default for x86 and armv7. It will be the
new GenericScheduler for subtargets that don't provide their own
SchedulingStrategy.

llvm-svn: 191051

llvm-svn: 191050

C-like languages promote types like unsigned short to unsigned int before
performing an arithmetic operation. Currently the rotate matcher in the
DAGCombiner does not consider this situation.

This commit extends the DAGCombiner in the way that the pattern

(or (shl ([az]ext x), (*ext y)), (srl ([az]ext x), (*ext (sub 32, y))))

is folded into

([az]ext (rotl x, y))

The matching is restricted to aext and zext because in this cases the upper
bits are either undefined or known. Test case is included.

This fixes PR16726.

llvm-svn: 191049

There is a buildbot failure. Need to investigate this.

llvm-svn: 191048

C-like languages promote types like unsigned short to unsigned int before
performing an arithmetic operation. Currently the rotate matcher in the
DAGCombiner does not consider this situation.

This commit extends the DAGCombiner in the way that the pattern

(or (shl ([az]ext x), (*ext y)), (srl ([az]ext x), (*ext (sub 32, y))))

is folded into

([az]ext (rotl x, y))

The matching is restricted to aext and zext because in this cases the upper
bits are either undefined or known. Test case is included.

This fixes PR16726.

llvm-svn: 191045

llvm-svn: 191043

Patch by Tom Roeder!

llvm-svn: 191042

<rdar://problem/7859988>

llvm-svn: 191040

llvm-svn: 191039

  If "C1/X" were having multiple uses, the only benefit of this
transformation is to potentially shorten critical path. But it is at the
cost of instroducing additional div.

  The additional div may or may not incur cost depending on how div is
implemented. If it is implemented using Newton–Raphson iteration, it dosen't
seem to incur any cost (FIXME). However, if the div blocks the entire
pipeline, that sounds to be pretty expensive. Let CodeGen to take care 
this transformation.

  This patch sees 6% on a benchmark.

rdar://15032743

llvm-svn: 191037

The code below can't handle any pointers. PR17293.

llvm-svn: 191036

Based on code review feedback from Eric Christopher, unshifting these
constants as they can appear in the gdb_index itself, shifted a further
24 bits. This means that keeping them preshifted is a bit inflexible, so
let's not do that.

Given the motivation, wrap up some nicer enums, more type safety, and
some utility functions.

llvm-svn: 191035

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

llvm-svn: 191030

This avoids warnings when included in a application that
uses -Wstrict-prototypes.

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

llvm-svn: 191029

in normally.

llvm-svn: 191026