- May 13, 2009
-
-
Evan Cheng authored
llvm-svn: 71606
-
- May 12, 2009
-
-
John Mosby authored
Restructure PEI code: - moved shrink wrapping code from PrologEpilogInserter.cpp to new file ShrinkWrapping.cpp. - moved PEI pass definition into new shared header PEI.h. llvm-svn: 71588
-
Jay Foad authored
llvm-svn: 71587
-
Evan Cheng authored
Fixed a stack slot coloring with reg bug: do not update implicit use / def when doing forward / backward propagation. llvm-svn: 71574
-
Bob Wilson authored
after finding the (unique) layout predecessor. Sometimes a block may be listed more than once, and processing it more than once in this loop can lead to inconsistent values for FtTBB/FtFBB, since the AnalyzeBranch method does not clear these values. There's no point in continuing the loop regardless. The testcase for this is reduced from the 2003-05-02-DependentPHI SingleSource test. llvm-svn: 71536
-
Bill Wendling authored
blast it away. - Move InlineInfo bookkeeping to bookkeep the correct debug info object. llvm-svn: 71519
-
Lang Hames authored
llvm-svn: 71495
-
- May 11, 2009
-
-
Dale Johannesen authored
sucessor info. llvm-svn: 71478
-
Evan Cheng authored
llvm-svn: 71472
-
Evan Cheng authored
llvm-svn: 71457
-
Evan Cheng authored
llvm-svn: 71456
-
Dan Gohman authored
type, rather than assume that it does. If the operand is not vector, it shouldn't be run through ScalarizeVectorOp. This fixes one of the testcases in PR3886. llvm-svn: 71453
-
John Mosby authored
Shrink wrapping in PEI: - reduces _static_ callee saved register spills and restores similar to Chow's original algorithm. - iterative implementation with simple heuristic limits to mitigate compile time impact. - handles placing spills/restores for multi-entry, multi-exit regions in the Machine CFG without splitting edges. - passes test-suite in LLCBETA mode. Added contains() method to ADT/SparseBitVector. llvm-svn: 71438
-
Jay Foad authored
memcpy, memmove and memset. llvm-svn: 71427
-
Bill Wendling authored
The DwarfWriter expects DbgScopes and DIEs to behave themselves according to DwarfWriter's rules. However, inlined functions violate these rules. There are two different types of DIEs associated with an inlined function: an abstract instance, which has information about the original source code for the function being inlined; and concrete instances, which are created for each place the function was inlined and point back to the abstract instance. This patch tries to stay true to this schema. It bypasses how regular DbgScopes and DIEs are created and used when necessary. It provides special handling for DIEs of abstract and concrete instances. This doesn't take care of all of the problems with debug info for inlined functions, but it's a step in the right direction. For one thing, llvm-gcc generates wrong IR (it's missing some llvm.dbg intrinsics at the point where the function's inlined) for this example: #include <stdio.h> static __inline__ __attribute__((always_inline)) int bar(int x) { return 4; } void foo() { long long b = 1; int Y = bar(4); printf("%d\n", Y); } while clang generates correct IR. llvm-svn: 71410
-
- May 10, 2009
-
-
Bill Wendling authored
U lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp Revert r71370. llvm-svn: 71373
-
Bill Wendling authored
None. However, we were always recording the region end. There's no longer a good reason for this code to be separated out between the different opt levels, as it was doing pretty much the same thing anyway. llvm-svn: 71370
-
- May 09, 2009
-
-
Evan Cheng authored
llvm-svn: 71363
-
Duncan Sands authored
will make it more obvious what it represents, and stop it being confused with the StoreSize. llvm-svn: 71349
-
Evan Cheng authored
llvm-svn: 71291
-
Mike Stump authored
llvm-svn: 71275
-
- May 08, 2009
-
-
Bill Wendling authored
inlined function or the end of a function. Before, this was never executing the "inlined" version of the Record method. This will become important once the inlined Dwarf writer patch lands. llvm-svn: 71268
-
Bill Wendling authored
concrete instance of an inlined function, we can get the actual address of the abstract instance inside of the compile unit. This isn't currently used, but will be by a future check-in. llvm-svn: 71263
-
Bill Wendling authored
llvm-svn: 71256
-
Evan Cheng authored
llvm-svn: 71242
-
Anton Korobeynikov authored
llvm-svn: 71241
-
Anton Korobeynikov authored
llvm-svn: 71240
-
Anton Korobeynikov authored
llvm-svn: 71238
-
Anton Korobeynikov authored
llvm-svn: 71237
-
Evan Cheng authored
llvm-svn: 71214
-
Nick Lewycky authored
llvm-svn: 71211
-
Evan Cheng authored
Optimize code placement in loop to eliminate unconditional branches or move unconditional branch to the outside of the loop. e.g. /// A: /// ... /// <fallthrough to B> /// /// B: --> loop header /// ... /// jcc <cond> C, [exit] /// /// C: /// ... /// jmp B /// /// ==> /// /// A: /// ... /// jmp B /// /// C: --> new loop header /// ... /// <fallthough to B> /// /// B: /// ... /// jcc <cond> C, [exit] llvm-svn: 71209
-
Bob Wilson authored
scavenger gets confused about register liveness if it doesn't see them. I'm not thrilled with this solution, but it only comes up when there are dead copies in the code, which is something that hopefully doesn't happen much. Here is what happens in pr4100: As shown in the following excerpt from the debug output of llc, the source of a move gets reloaded from the stack, inserting a new load instruction before the move. Since that source operand is a kill, the physical register is free to be reused for the destination of the move. The move ends up being a no-op, copying R3 to R3, so it is deleted. But, it leaves behind the load to reload %reg1028 into R3, and that load is not updated to show that it's destination operand (R3) is dead. The scavenger gets confused by that load because it thinks that R3 is live. Starting RegAlloc of: %reg1025<def,dead> = MOVr %reg1028<kill>, 14, %reg0, %reg0 Regs have values: Reloading %reg1028 into R3 Last use of R3[%reg1028], removing it from live set Assigning R3 to %reg1025 Register R3 [%reg1025] is never used, removing it from live set Alternative solutions might be either marking the load as dead, or zapping the load along with the no-op copy. I couldn't see an easy way to do either of those, though. llvm-svn: 71196
-
- May 07, 2009
-
-
Bob Wilson authored
llvm-svn: 71180
-
Bob Wilson authored
llvm-svn: 71179
-
Dan Gohman authored
several regressions. The problem due to 71158 is now fixed. llvm-svn: 71176
-
Bill Wendling authored
checking for bcopy... no checking for getc_unlocked... Assertion failed: (0 && "Unknown SCEV kind!"), function operator(), file /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore.roots/llvmCore~obj/src/lib/Analysis/ScalarEvolution.cpp, line 511. /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~obj/src/libdecnumber/decUtility.c:360: internal compiler error: Abort trap Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://developer.apple.com/bugreporter> for instructions. make[4]: *** [decUtility.o] Error 1 make[4]: *** Waiting for unfinished jobs.... Assertion failed: (0 && "Unknown SCEV kind!"), function operator(), file /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore.roots/llvmCore~obj/src/lib/Analysis/ScalarEvolution.cpp, line 511. /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~obj/src/libdecnumber/decNumber.c:5591: internal compiler error: Abort trap Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://developer.apple.com/bugreporter> for instructions. make[4]: *** [decNumber.o] Error 1 make[3]: *** [all-stage2-libdecnumber] Error 2 make[3]: *** Waiting for unfinished jobs.... llvm-svn: 71165
-
Argyrios Kyrtzidis authored
No functionality change. llvm-svn: 71156
-
Evan Cheng authored
llvm-svn: 71151
-
Evan Cheng authored
llvm-svn: 71150
-