- Oct 18, 2009
-
-
Evan Cheng authored
llvm-svn: 84431
-
Evan Cheng authored
llvm-svn: 84425
-
Evan Cheng authored
stack slots and giving them different PseudoSourceValue's did not fix the problem of post-alloc scheduling miscompiling llvm itself. - Apply Dan's conservative workaround by assuming any non fixed stack slots can alias other memory locations. This means a load from spill slot #1 cannot move above a store of spill slot #2. - Enable post-alloc scheduling for x86 at optimization leverl Default and above. llvm-svn: 84424
-
Evan Cheng authored
llvm-svn: 84411
-
- Oct 17, 2009
-
-
Evan Cheng authored
Distinquish stack slots from other stack objects. They (and fixed objects) get FixedStack PseudoSourceValues. llvm-svn: 84326
-
Evan Cheng authored
llvm-svn: 84321
-
Evan Cheng authored
necessarily fixed. Only those will negative frame indices are "fixed." llvm-svn: 84315
-
Victor Hernandez authored
llvm-svn: 84299
-
- Oct 16, 2009
-
-
Evan Cheng authored
llvm-svn: 84273
-
Benjamin Kramer authored
llvm-svn: 84252
-
Sanjiv Gupta authored
llvm-svn: 84251
-
Evan Cheng authored
llvm-svn: 84250
-
Evan Cheng authored
llvm-svn: 84249
-
Evan Cheng authored
llvm-svn: 84246
-
Bob Wilson authored
Patch by Johnny Chen. llvm-svn: 84243
-
Bob Wilson authored
I can see with the original code was that I forgot that this runs after type legalization and hence the result type will always be i32. (Custom legalization of EXTRACT_VECTOR_ELT is only enabled for vector types with 8- and 16-bit elements.) Regarding the FIXME comment: any information about sign and zero-extension should be captured by separate extension operations. The DAG combiner should handle those to produce either VGETLANEu or VGETLANEs, and that seems to be working now. If there are cases that we're missing, let me know. llvm-svn: 84218
-
Anton Korobeynikov authored
1. Emit external function type information for all COFF targets since it's a feature of object format 2. Emit linker directives only for cygming (since this is ld-specific stuff) llvm-svn: 84214
-
Sandeep Patel authored
llvm-svn: 84212
-
- Oct 15, 2009
-
-
Bob Wilson authored
Patch by Johnny Chen. llvm-svn: 84206
-
Kevin Enderby authored
is just "[Rn]" and no tailing comma with an offset, etc. llvm-svn: 84205
-
Bob Wilson authored
In the case where there are no good places to put constants and we fall back upon inserting unconditional branches to make new blocks, allow all constant pool references in range of those blocks to put constants there, even if that means resetting the "high water marks" for those references. This will still terminate because you can't keep splitting blocks forever, and in the bad cases where we have to split blocks, it is important to avoid splitting more than necessary. llvm-svn: 84202
-
Kevin Enderby authored
as expressions, code for parsing a few arm specific directives (still needs the MCStreamer calls for these). Some clean up of the operand parsing code and adding some comments. llvm-svn: 84201
-
Evan Cheng authored
llvm-svn: 84200
-
Benjamin Kramer authored
llvm-svn: 84196
-
Sanjiv Gupta authored
llvm-svn: 84195
-
Jakob Stoklund Olesen authored
llvm-svn: 84194
-
Jakob Stoklund Olesen authored
llvm-svn: 84192
-
Daniel Dunbar authored
PIC16Section class", it breaks globals.ll. llvm-svn: 84184
-
Sanjiv Gupta authored
derived from MCSection. llvm-svn: 84180
-
Sanjiv Gupta authored
llvm-svn: 84179
-
Bob Wilson authored
llvm-svn: 84173
-
Bob Wilson authored
When ARMConstantIslandPass cannot find any good locations (i.e., "water") to place constants, it falls back to inserting unconditional branches to make a place to put them. My recent change exposed a problem in this area. We may sometimes append to the same block more than one unconditional branch. The symptoms of this are that the generated assembly has a branch to an undefined label and running llc with -debug will cause a seg fault. This happens more easily since my change to prevent CPEs from moving from lower to higher addresses as the algorithm iterates, but it could have happened before. The end of the block may be in range for various constant pool references, but the insertion point for new CPEs is not right at the end of the block -- it is at the end of the CPEs that have already been placed at the end of the block. The insertion point could be out of range. When that happens, the fallback code will always append another unconditional branch if the end of the block is in range. The fix is to only append an unconditional branch if the block does not already end with one. I also removed a check to see if the constant pool load instruction is at the end of the block, since that is redundant with checking if the end of the block is in-range. There is more to be done here, but I think this fixes the immediate problem. llvm-svn: 84172
-
- Oct 14, 2009
-
-
Bob Wilson authored
Patch by Johnny Chen. llvm-svn: 84146
-
Bob Wilson authored
llvm-svn: 84144
-
Jim Grosbach authored
Refs: A7-17 & A8-750. Patch by Johnny Chen. llvm-svn: 84131
-
Bob Wilson authored
register-shifted-register instructions. Patch by Johnny Chen. llvm-svn: 84124
-
Bob Wilson authored
llvm-svn: 84122
-
Bob Wilson authored
llvm-svn: 84117
-
Bob Wilson authored
vld lane intrinsics. llvm-svn: 84110
-
Bob Wilson authored
llvm-svn: 84109
-