- Dec 23, 2008
-
-
Dan Gohman authored
code in ScheduleDAGSDNodes' BuildSchedGraph into separate functions. llvm-svn: 61376
-
Dan Gohman authored
llvm-svn: 61374
-
Dan Gohman authored
several places. isTerminator() returns true for a superset of cases, and includes things like FP_REG_KILL, which are nither return or branch but aren't safe to move/remat/etc. llvm-svn: 61373
-
Dan Gohman authored
llvm-svn: 61372
-
Dan Gohman authored
llvm-svn: 61371
-
Zhongxing Xu authored
llvm-svn: 61369
-
Zhongxing Xu authored
llvm-svn: 61368
-
Mon P Wang authored
llvm-svn: 61366
-
Mon P Wang authored
Fixed lowering of v8i16 shuffles for v8i16 when we fall back to extract/insert. llvm-svn: 61365
-
Dale Johannesen authored
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. 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. Also, the mechanism for keeping SCEV's corresponding to GEP's no longer works, as the GEP might change after its SCEV is remembered, invalidating the SCEV, and we might get a bad SCEV value when looking up the GEP again for a later loop. This also couldn't happen before, as we weren't recursing into GEP's outside the loop. I owe some testcases for this, want to get it in for nightly runs. llvm-svn: 61362
-
Dale Johannesen authored
llvm-svn: 61361
-
Owen Anderson authored
llvm-svn: 61358
-
Dan Gohman authored
llvm-svn: 61356
-
- Dec 22, 2008
-
-
Bill Wendling authored
llvm-svn: 61354
-
Bill Wendling authored
llvm-svn: 61353
-
Bill Wendling authored
llvm-svn: 61352
-
Bill Wendling authored
llvm-svn: 61350
-
Bill Wendling authored
llvm-svn: 61349
-
Bill Wendling authored
truely deleted. These will be expanded with further checks of all of the data structures. llvm-svn: 61347
-
Dan Gohman authored
functions. llvm-svn: 61345
-
Dan Gohman authored
up on a profile. llvm-svn: 61344
-
Dan Gohman authored
reallocations. We don't do cloning on MachineInstr schedule DAGs, but this is a worthwhile sanity check regardless. llvm-svn: 61343
-
Dan Gohman authored
llvm-svn: 61342
-
Dan Gohman authored
comment for the ScheduleDAGSDNodes class. llvm-svn: 61341
-
Dan Gohman authored
llvm-svn: 61338
-
- Dec 21, 2008
-
-
Mikhail Glushenkov authored
llvm-svn: 61307
-
Nick Lewycky authored
llvm-svn: 61297
-
- Dec 20, 2008
-
-
Dan Gohman authored
constant shift count that doesn't fit in the shift instruction's immediate field. This fixes PR3242. llvm-svn: 61281
-
Dan Gohman authored
llvm-svn: 61280
-
Nick Lewycky authored
our optz'n will apply to it, then build the replacement vector only if needed. llvm-svn: 61279
-
Dan Gohman authored
can be static member functions. llvm-svn: 61278
-
Dan Gohman authored
llvm-svn: 61277
-
Dan Gohman authored
and setDepthDirty(), respectively. This fixes PR3241. llvm-svn: 61276
-
- Dec 19, 2008
-
-
Bill Wendling authored
llvm-svn: 61265
-
Bill Wendling authored
llvm-svn: 61264
-
Dan Gohman authored
warnings on compilers that warn about such things. llvm-svn: 61263
-
Evan Cheng authored
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
-
John Criswell authored
version number assertions. llvm-svn: 61257
-
Bill Wendling authored
llvm-svn: 61254
-
Gordon Henriksen authored
llvm-svn: 61253
-