llvm-svn: 61184

folding's tail merging doesn't currently preserve liveness information
which post-RA scheduling requires.

llvm-svn: 61183

llvm-svn: 61182

llvm-svn: 61181

and the RegisterScavenger not to expect traditional liveness 
techniques are applicable to these registers, since we don't fully
modify the effects of push and pop after stackification.

llvm-svn: 61179

my last patch to this file.

The issue there was that all uses of an IV inside a loop
are actually references to Base[IV*2], and there was one
use outside that was the same but LSR didn't see the base
or the scaling because it didn't recurse into uses outside
the loop; thus, it used base+IV*scale mode inside the loop
instead of pulling base out of the loop.  This was extra bad
because register pressure later forced both base and IV into
memory.  Doing that recursion, at least enough
to figure out addressing modes, is a good idea in general;
the change in AddUsersIfInteresting does this.  However,
there were side effects....

It is also possible for recursing outside the loop to
introduce another IV where there was only 1 before (if
the refs inside are not scaled and the ref outside is).
I don't think this is a common case, but it's in the testsuite.
It is right to be very aggressive about getting rid of
such introduced IVs (CheckForIVReuse and the handling of
nonzero RewriteFactor in StrengthReduceStridedIVUsers).
In the testcase in question the new IV produced this way
has both a nonconstant stride and a nonzero base, neither
of which was handled before.  (This patch does not handle 
all the cases where this can happen.)  And when inserting 
new code that feeds into a PHI, it's right to put such 
code at the original location rather than in the PHI's 
immediate predecessor(s) when the original location is outside 
the loop (a case that couldn't happen before)
(RewriteInstructionToUseNewBase); better to avoid making
multiple copies of it in this case.

Everything above is exercised in
CodeGen/X86/lsr-negative-stride.ll (and ifcvt4 in ARM which is
the same IR).

llvm-svn: 61178

and safe and orthogonal from turning off load pre.

llvm-svn: 61177

llvm-svn: 61176

llvm-svn: 61175

llvm-svn: 61174

with everyone's favorite error messages:

Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
Bootstrap comparison failure!
./c-decl.o differs
./cp/decl.o differs
./df-core.o differs
./gcc.o differs
./i386.o differs
./stor-layout.o differs
./tree-pretty-print.o differs
./tree.o differs
make[2]: *** [compare] Error 1
make[1]: *** [stage3-bubble] Error 2

See PR3227.

llvm-svn: 61169

XFAIL for now.

llvm-svn: 61167

llvm-svn: 61166

Today the front-ends (llvm-gcc and clang) generate multiple llvm.dbg.compile_units to identify source file for various debug entities. Each llvm.dbg.compile_unit matches one file on the disk. However, the backend only supports one DW_TAG_compile_unit per .o file. The backend selects first compile_unit from the vector to construct DW_TAG_compile_unit entry, which is not correct in all cases.

First step to resolve this is, record file name and directory directly in debug info for various debug entities. 

llvm-svn: 61164

llvm-svn: 61159

llvm-svn: 61158

- ability to insert previously created instructions using a builder
- creation of aliases
- creation of inline asm constants

Patch by Zoltan Varga!

llvm-svn: 61153

llvm-svn: 61150

llvm-svn: 61143

always-current SVN version.

llvm-svn: 61142

llvm-svn: 61138

llvm-svn: 61129

iterator invalidation problems.

llvm-svn: 61124

nodes.  This allows it to do fairly general phi insertion if a 
load from a pointer global wants to be SRAd but the load is used
by (recursive) phi nodes.  This fixes a pessimization on ppc
introduced by Load PRE.

llvm-svn: 61123

temporary workaround for an obscure bug. When node cloning is
used, it is possible that more SUnits will be created, and
if the SUnits std::vector has to reallocate, it will
invalidate all the graph edges.

llvm-svn: 61122

Depth and Height members directly, as they may not be
current.

llvm-svn: 61121

llvm-svn: 61120

DAGTypeLegalizer::ExpandShiftWithKnownAmountBit.

In terms of restoring the optimization, the best fix here isn't 
obvious... any ideas?

llvm-svn: 61119

llvm-svn: 61118

Add (error) and (empty).

llvm-svn: 61117

can be negative.  Keep track of whether all uses of
an IV are outside the loop.  Some cosmetics; no
functional change.

llvm-svn: 61109

are there under ADD, this one was missing.

llvm-svn: 61107

Add code to renumber split intervals into new vregs.  This is disabled for now until I finish working out some iterator invalidation issues.

llvm-svn: 61104

the load multiple times, make sure the check the uses of the PHI to 
ensure they are transformable.

llvm-svn: 61102

llvm-svn: 61101

consistently for deleting branches.  In addition to being slightly 
more readable, this makes SimplifyCFG a bit better 
about cleaning up after itself when it makes conditions unused.

llvm-svn: 61100

position in the critical path during the main instruction walk.  This
eliminates the need for the CritialAntiDep DenseMap.

llvm-svn: 61096

llvm-svn: 61095

builds.

llvm-svn: 61094

different offsets within the same stack slot.

llvm-svn: 61093