Fix PR3149. If an early clobber def is a physical register and it is tied to an input operand, it effectively extends the live range of the physical register. Currently we do not have a good way to represent this.

172     %ECX<def> = MOV32rr %reg1039<kill>
180     INLINEASM <es:subl $5,$1
        sbbl $3,$0>, 10, %EAX<def>, 14, %ECX<earlyclobber,def>, 9, %EAX<kill>,
36, <fi#0>, 1, %reg0, 0, 9, %ECX<kill>, 36, <fi#1>, 1, %reg0, 0
188     %EAX<def> = MOV32rr %EAX<kill>
196     %ECX<def> = MOV32rr %ECX<kill>
204     %ECX<def> = MOV32rr %ECX<kill>
212     %EAX<def> = MOV32rr %EAX<kill>
220     %EAX<def> = MOV32rr %EAX
228     %reg1039<def> = MOV32rr %ECX<kill>

The early clobber operand ties ECX input to the ECX def.

The live interval of ECX is represented as this:
%reg20,inf = [46,47:1)[174,230:0)  0@174-(230) 1@46-(47)

The right way to represent this is something like
%reg20,inf = [46,47:2)[174,182:1)[181:230:0)  0@174-(182) 1@181-230 @2@46-(47)

Of course that won't work since that means overlapping live ranges defined by two val#.

The workaround for now is to add a bit to val# which says the val# is redefined by a early clobber def somewhere. This prevents the move at 228 from being optimized away by SimpleRegisterCoalescing::AdjustCopiesBackFrom.

llvm-svn: 61259

version number assertions.

llvm-svn: 61257

This operation can be used to build dyn_cast, isa, and cast.

llvm-svn: 61252

Patch by Lukasz Janyst!

llvm-svn: 61251

that have i32 immediates so that they get selected first. This
currently only matters in the JIT, as assemblers will
automatically use the smallest encoding.

llvm-svn: 61250

- CodeGenPrepare does not split loop back edges but it only knows about back edges of single block loops. It now does a DFS walk to find loop back edges.
- Use SplitBlockPredecessors to factor out common predecessors of the critical edge destination. This is disabled for now due to some regressions.

llvm-svn: 61248

llvm-svn: 61244

The EH_frame and .eh symbols are now private, except for darwin9 and earlier.
The patch also fixes the definition of PrivateGlobalPrefix on pcc linux.

llvm-svn: 61242

llvm-svn: 61241

llvm-svn: 61240

The problematic part of this patch is that we were out of attribute bits,
requiring some fancy bit hacking to make it fit (by shrinking alignment)
without breaking existing users or the file format.

This change will require users to rebuild llvm-gcc to match llvm.

llvm-svn: 61239

llvm-svn: 61238

data from a previous block.

llvm-svn: 61237

llvm-svn: 61222

subreg instructions.

llvm-svn: 61220

llvm-svn: 61219

that of INSERT_SUBREG and SUBREG_TO_REG.

llvm-svn: 61218

llvm-svn: 61217

llvm-svn: 61216

used, mark the defs as dead.

llvm-svn: 61215

non-entry blocks, so that it doesn't appear use-before-def anywhere.

llvm-svn: 61214

llvm-svn: 61213

llvm-svn: 61211

llvm-svn: 61209

llvm-svn: 61201

Simplifying the sdiv might allow further simplifications for our users.

llvm-svn: 61196

llvm-svn: 61195

bit from the original function to the cloned one.

llvm-svn: 61194

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: 61175

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

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