- Dec 04, 2012
-
-
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
-
Argyrios Kyrtzidis authored
llvm-svn: 169163
-
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
-
Argyrios Kyrtzidis authored
For comparison, with this code sample: PointerUnion<int *, char *> Data; PointerUnion<int *, char *> foo1() { Data = new int; return new int; } PointerUnion<int *, char *> foo2() { Data = new char; return new char; } Before this patch we would get: define i64 @_Z4foo1v() uwtable ssp { %1 = tail call noalias i8* @_Znwm(i64 4) %2 = ptrtoint i8* %1 to i64 %3 = load i64* getelementptr inbounds (%"class.llvm::PointerUnion"* @Data, i64 0, i32 0, i32 0), align 8 %4 = and i64 %3, 1 %.masked.i = and i64 %2, -3 %5 = or i64 %4, %.masked.i store i64 %5, i64* getelementptr inbounds (%"class.llvm::PointerUnion"* @Data, i64 0, i32 0, i32 0), align 8 %6 = tail call noalias i8* @_Znwm(i64 4) %7 = ptrtoint i8* %6 to i64 %8 = and i64 %7, -3 ret i64 %8 } define i64 @_Z4foo2v() uwtable ssp { %1 = tail call noalias i8* @_Znwm(i64 1) %2 = ptrtoint i8* %1 to i64 %3 = load i64* getelementptr inbounds (%"class.llvm::PointerUnion"* @Data, i64 0, i32 0, i32 0), align 8 %4 = and i64 %3, 1 %5 = or i64 %2, %4 %6 = or i64 %5, 2 store i64 %6, i64* getelementptr inbounds (%"class.llvm::PointerUnion"* @Data, i64 0, i32 0, i32 0), align 8 %7 = tail call noalias i8* @_Znwm(i64 1) %8 = ptrtoint i8* %7 to i64 %9 = or i64 %8, 2 ret i64 %9 } After the patch: define i64 @_Z4foo1v() uwtable ssp { %1 = tail call noalias i8* @_Znwm(i64 4) %2 = ptrtoint i8* %1 to i64 store i64 %2, i64* getelementptr inbounds (%"class.llvm::PointerUnion"* @Data, i64 0, i32 0, i32 0), align 8 %3 = tail call noalias i8* @_Znwm(i64 4) %4 = ptrtoint i8* %3 to i64 ret i64 %4 } declare noalias i8* @_Znwm(i64) define i64 @_Z4foo2v() uwtable ssp { %1 = tail call noalias i8* @_Znwm(i64 1) %2 = ptrtoint i8* %1 to i64 %3 = or i64 %2, 2 store i64 %3, i64* getelementptr inbounds (%"class.llvm::PointerUnion"* @Data, i64 0, i32 0, i32 0), align 8 %4 = tail call noalias i8* @_Znwm(i64 1) %5 = ptrtoint i8* %4 to i64 %6 = or i64 %5, 2 ret i64 %6 } llvm-svn: 169147
-
Eli Bendersky authored
is not yet good enough for more sophistication. The important goal of this test is to make sure llc doesn't crash on this IR like it used to. llvm-svn: 169146
-
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
AKA: Recompile *ALL* the source code! This one went much better. No manual edits here. I spot-checked for silliness and grep-checked for really broken edits and everything seemed good. It all still compiles. Yell if you see something that looks goofy. llvm-svn: 169133
-
Chandler Carruth authored
Kind of important when prepping the include/... tree version of the sort changes. llvm-svn: 169132
-
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
-
Chris Lattner authored
llvm-svn: 169130
-
Chandler Carruth authored
standards. I am a terrible Python programmer. Patches more the welcome. Please tell me how this should look if it should look differently. It's just a tiny little script so it didn't make sense to go through pre-commit review, especially as someone who actually knows python may want to just rip it apart and do it The Right Way. I will be preparing a commit shortly that uses this script to canonicalize *all* of the #include lines in LLVM. Really, all of them. llvm-svn: 169125
-
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
-