- Dec 04, 2012
-
-
Jakob Stoklund Olesen authored
Targets can provide multiple hints now, so getRegAllocPref() doesn't make sense any longer because it only returns one preferred register. Replace it with getSimpleHint() in the remaining heuristics. This function only llvm-svn: 169188
-
Manman Ren authored
No functional change for this commit. The follow-up patch will add more stuff to these functions. rdar://12713765 llvm-svn: 169186
-
NAKAMURA Takumi authored
llvm-svn: 169183
-
rdar://12329730Shuxin Yang authored
This change tries to simmplify E1 = " X >> C1 << C2" into : - E2 = "X << (C2 - C1)" if C2 > C1, or - E2 = "X >> (C1 - C2)" if C1 > C2, or - E2 = X if C1 == C2. Reviewed by Nadav. Thanks! llvm-svn: 169182
-
Jakob Stoklund Olesen authored
Virtual registers with a known preferred register are prioritized by RAGreedy. This function makes the condition explicit without depending on getRegAllocPref(). llvm-svn: 169179
-
Akira Hatanaka authored
This small change adds support for that. It will make all MCJIT tests pass in make-check on BigEndian platforms. Patch by Petar Jovanovic. llvm-svn: 169178
-
Akira Hatanaka authored
This change adds endian-awareness to MipsJITInfo and emitWordLE in MipsCodeEmitter has become emitWord now to support both endianness. Patch by Petar Jovanovic. llvm-svn: 169177
-
- Dec 03, 2012
-
-
Michael Ilseman authored
llvm-svn: 169176
-
Nadav Rotem authored
llvm-svn: 169175
-
Akira Hatanaka authored
code. Removing it. Patch by Petar Jovanovic. llvm-svn: 169174
-
Jakob Stoklund Olesen authored
This simplifies the hinting code quite a bit while making the targets easier to write at the same time. llvm-svn: 169173
-
Nadav Rotem authored
llvm-svn: 169172
-
Nadav Rotem authored
llvm-svn: 169171
-
Jakob Stoklund Olesen authored
This provides the same functionality as getRawAllocationOrder() for the even/odd hints, but without the many constant register arrays. llvm-svn: 169169
-
Jyotsna Verma authored
using multiclass. llvm-svn: 169168
-
Michael J. Spencer authored
llvm-svn: 169167
-
Michael J. Spencer authored
llvm-svn: 169166
-
Michael J. Spencer authored
"Windows.h" includes <Windows.h> which defines a bunch of stuff it shouldn't (even with all the restriction macros). We have no control over this file, so make it's scope as small as possible. llvm-svn: 169165
-
Pedro Artigas authored
moves doInitialization and doFinalization to the Pass class and removes some unreachable code in MachineModuleInfo reviewed by Evan Cheng <evan.cheng@apple.com> llvm-svn: 169164
-
Nadav Rotem authored
"single basic block loop vectorizer" to "innermost loop vectorizer". llvm-svn: 169158
-
Michael Ilseman authored
Since this SmallVector immediately grows on the next line, don't waste stack space. SmallVector is still needed due to existing APIs growing their arguments llvm-svn: 169157
-
Jakob Stoklund Olesen authored
The TargetRegisterInfo::getRegAllocationHints() function is going to replace the existing mechanisms for providing target-dependent hints to the register allocator: ResolveRegAllocHint() and getRawAllocationOrder(). The new hook is more flexible because it allows the target to provide multiple preferred candidate registers for each virtual register, and it is easier to use because targets are not required to return a reference to a constant array like getRawAllocationOrder(). An optional VirtRegMap argument can be used to provide target-dependent hints that depend on the provisional assignments of other virtual registers. llvm-svn: 169154
-
Jyotsna Verma authored
using multiclass. llvm-svn: 169153
-
Nadav Rotem authored
which is the legality of the if-conversion transformation. The next step is to implement the cost-model for the if-converted code as well as the vectorization itself. llvm-svn: 169152
-
Jyotsna Verma authored
llvm-svn: 169149
-
Jyotsna Verma authored
llvm-svn: 169148
-
Bill Wendling authored
llvm-svn: 169145
-
Alexey Samsonov authored
llvm-svn: 169143
-
Eli Bendersky authored
Thanks Eric for the review. llvm-svn: 169142
-
Nadav Rotem authored
Teach the jump threading optimization to stop scanning the basic block when calculating the cost after passing the threshold. llvm-svn: 169135
-
Jakob Stoklund Olesen authored
llvm-svn: 169134
-
Chandler Carruth authored
Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
-
Chandler Carruth authored
The partitioning logic attempted to handle uses of an alloca with an offset starting before the alloca so long as the use had some overlap with the alloca itself. However, there was a bug where we tested '(uint64_t)Offset >= AllocSize' without first checking whether 'Offset' was positive. As a consequence, essentially every negative offset (that is, starting *before* the alloca does) would be thrown out, even if it was overlapping. The subsequent code to throw out negative offsets which were actually non-overlapping was essentially dead. The code to *handle* overlapping negative offsets was actually dead! I've just removed all of this, and taught SROA to discard any uses which start prior to the alloca from the beginning. It has the lovely property of simplifying the code. =] All the tests still pass, and in fact no new tests are needed as this is already covered by our testsuite. Fixing the code so that negative offsets work the way the comments indicate they were supposed to work causes regressions. That's how I found this. Anyways, this is all progress in the correct direction -- tightening up SROA to be maximally aggressive. Some day, I really hope to turn out-of-bounds accesses to an alloca into 'unreachable'. llvm-svn: 169120
-
Nuno Lopes authored
llvm-svn: 169119
-
Jyotsna Verma authored
llvm-svn: 169117
-
- Dec 02, 2012
-
-
Nadav Rotem authored
llvm-svn: 169111
-
- Dec 01, 2012
-
-
Benjamin Kramer authored
Fixes PR14465. Differential Revision: http://llvm-reviews.chandlerc.com/D148 llvm-svn: 169084
-
Zhou Sheng authored
llvm-svn: 169083
-
Zhou Sheng authored
Also check in a case to repeat the issue, on which 'opt -globalopt' consumes 1.6GB memory. The big memory footprint cause is that current GlobalOpt one by one hoists and stores the leaf element constant into the global array, in each iteration, it recreates the global array initializer constant and leave the old initializer alone. This may result in many obsolete constants left. For example: we have global array @rom = global [16 x i32] zeroinitializer After the first element value is hoisted and installed: @rom = global [16 x i32] [ 1, 0, 0, ... ] After the second element value is installed: @rom = global [16 x 32] [ 1, 2, 0, 0, ... ] // here the previous initializer is obsolete ... When the transform is done, we have 15 obsolete initializers left useless. llvm-svn: 169079
-
NAKAMURA Takumi authored
2012-11-30-misched-dbg.ll had crashed. Then (MDNode)N was "!{}". I am not sure it would be ill-formed or not. llvm-svn: 169074
-