- Jun 09, 2012
-
-
Dmitri Gribenko authored
to a change done long ago in r57393. llvm-svn: 158243
-
Jakob Stoklund Olesen authored
The fast register allocator is not supposed to work in the optimizing pipeline. It doesn't make sense to compute live intervals, run full copy coalescing, and then run RAFast. Fast register allocation in the optimizing pipeline is better done by RABasic. llvm-svn: 158242
-
Dmitri Gribenko authored
llvm-svn: 158241
-
Jim Ingham authored
than being given the pthread_mutex_t from the Mutex and locks that. That allows us to track ownership of the Mutex better. Used this to switch the LLDB_CONFIGURATION_DEBUG enabled assert when we can't get the gdb-remote sequence mutex to assert when the thread that had the mutex releases it. This is generally more useful information than saying just who failed to get it (since the code that had it locked often had released it by the time the assert fired.) llvm-svn: 158240
-
Jordan Rose authored
This could happen for cases like this: - (NSArray *)getAllNames:(NSArray *)images { NSMutableArray *results = [NSMutableArray array]; for (auto img in images) { [results addObject:img.name]; } return results; } Here the property access will fail because 'img' has type 'id', rather than, say, NSImage. This warning will not fire in templated code, since the 'id' could have come from a template parameter. llvm-svn: 158239
-
Jordan Rose authored
llvm-svn: 158238
-
Nuno Lopes authored
-%a + 42 into 42 - %a previously we were emitting: -(%a + 42) This fixes the infinite loop in PR12338. The generated code is still not perfect, though. Will work on that next llvm-svn: 158237
-
Sean Callanan authored
- On iOS, we select the "apcs-gnu" ABI to match what libraries expect. - Literals are now allocated at their preferred alignment, eliminating many alignment crashes. llvm-svn: 158236
-
- Jun 08, 2012
-
-
Jim Ingham authored
Make raw & parsed commands subclasses of CommandObject rather than having the raw version implement an Execute which was never going to get run and another ExecuteRawCommandString. Took the knowledge of how to prepare raw & parsed commands out of CommandInterpreter and put it in CommandObject where it belongs. Also took all the cases where there were the subcommands of Multiword commands declared in the .h file for the overall command and moved them into the .cpp file. Made the CommandObject flags work for raw as well as parsed commands. Made "expr" use the flags so that it requires you to be paused to run "expr". llvm-svn: 158235
-
Evan Cheng authored
llvm-svn: 158234
-
Andrew Trick authored
llvm-svn: 158233
-
Johnny Chen authored
llvm-svn: 158232
-
Richard Smith authored
typo-correction after a scope specifier. llvm-svn: 158231
-
Jordan Rose authored
Objective-C literals conceptually always create new objects, but may be optimized by the compiler or runtime (constant folding, singletons, etc). Comparing addresses of these objects is relying on this optimization behavior, which is really an implementation detail. In the case of == and !=, offer a fixit to a call to -isEqual:, if the method is available. This fixit is directly on the error so that it is automatically applied. Most of the time, this is really a newbie mistake, hence the fixit. llvm-svn: 158230
-
Jordan Rose authored
This occurs when you have two insertions and the first one is so long that the second fixit's column is before the first fixit ends. The edits themselves don't actually overlap, but our command-line preview does. llvm-svn: 158229
-
Richard Smith authored
constexpr until we get to the end of the class definition. When that happens, be sure to remember that the class actually does have a constexpr constructor. This is a stopgap solution, which still doesn't cover the case of a class with multiple copy constructors (only some of which are constexpr). We should be performing constructor lookup when implicitly defining a constructor in order to determine whether all constructors it invokes are constexpr. llvm-svn: 158228
-
Duncan Sands authored
problem was that by moving instructions around inside the function, the pass could accidentally move the iterator being used to advance over the function too. Fix this by only processing the instruction equal to the iterator, and leaving processing of instructions that might not be equal to the iterator to later (later = after traversing the basic block; it could also wait until after traversing the entire function, but this might make the sets quite big). Original commit message: Grab-bag of reassociate tweaks. Unify handling of dead instructions and instructions to reoptimize. Exploit this to more systematically eliminate dead instructions (this isn't very useful in practice but is convenient for analysing some testcase I am working on). No need for WeakVH any more: use an AssertingVH instead. llvm-svn: 158226
-
Richard Trieu authored
variable which wasn't removed when the original patch was committed. llvm-svn: 158225
-
Hal Finkel authored
As Chris points out, this can now be removed! TODO: check if the associated section on viterbi's inner loop can also be removed. llvm-svn: 158224
-
Hal Finkel authored
Thanks to Jakob's help, this now causes no new test suite failures! Over the entire test suite, this gives an average 1% speedup. The largest speedups are: SingleSource/Benchmarks/Misc/pi - 108% SingleSource/Benchmarks/CoyoteBench/lpbench - 54% MultiSource/Benchmarks/Prolangs-C/unix-smail/unix-smail - 50% SingleSource/Benchmarks/Shootout/ary3 - 32% SingleSource/Benchmarks/Shootout-C++/matrix - 30% The largest slowdowns are: MultiSource/Benchmarks/mediabench/gsm/toast/toast - -30% MultiSource/Benchmarks/Prolangs-C/bison/mybison - -25% MultiSource/Benchmarks/BitBench/uuencode/uuencode - -22% MultiSource/Applications/d/make_dparser - -14% SingleSource/Benchmarks/Shootout-C++/ary - -13% In light of these slowdowns, additional profiling work is obviously needed! llvm-svn: 158223
-
Johnny Chen authored
Previous fix to add convenience registers for x86_64 did not take the 'process attach' scenario into account. This patch fixes that. llvm-svn: 158222
-
Hal Finkel authored
Marking these classes as non-alocatable allows CTR loop generation to work correctly with the block placement passes, etc. These register classes are currently used only by some unused TCRETURN patterns. In future cleanup, these will be removed. Thanks again to Jakob for suggesting this fix to the CTR loop problem! llvm-svn: 158221
-
Manman Ren authored
llvm-svn: 158220
-
Anna Zaks authored
to addition. We should not to warn in case the malloc size argument is an addition containing 'sizeof' operator - it is common to use the pattern to pack values of different sizes into a buffer. Ex: uint8_t *buffer = (uint8_t*)malloc(dataSize + sizeof(length)); llvm-svn: 158219
-
Manman Ren authored
llvm-svn: 158218
-
Andrew Trick authored
This fixes an accidental dependence on static initialization order that I introduced yesterday. Thank you Lang!!! llvm-svn: 158215
-
Jordan Rose authored
The preprocessor's handling of diagnostic push/pops is stateful, so encountering pragmas during a re-parse causes problems. HTMLRewrite already filters out normal # directives including #pragma, so it's clear it's not expected to be interpreting pragmas in this mode. This fix adds a flag to Preprocessor to explicitly disable pragmas. The "right" fix might be to separate pragma lexing from pragma parsing so that we can throw away pragmas like we do preprocessor directives, but right now it's important to get the fix in. Note that this has nothing to do with the "hack" of re-using the input preprocessor in HTMLRewrite. Even if we someday copy the preprocessor instead of re-using it, the copy would (and should) include the diagnostic level tables and have the same problems. llvm-svn: 158214
-
Chad Rosier authored
Patch by James Benton <jbenton@vmware.com>. llvm-svn: 158213
-
Andrew Trick authored
Bulk move of TargetInstrInfo implementation into TargetInstrInfoImpl. This is dirty because the code isn't part of TargetInstrInfoImpl class, nor should it be, because the methods are not target hooks. However, it's the current mechanism for keeping libTarget useful outside the backend. You'll get a not-so-nice link error if you invoke a TargetInstrInfo method that depends on CodeGen. The TargetInstrInfoImpl class should probably be removed since it doesn't really solve this problem. To really fix this, we probably need separate interfaces for the CodeGen/nonCodeGen sides of TargetInstrInfo. llvm-svn: 158212
-
Douglas Gregor authored
from Tom Honermann! llvm-svn: 158211
-
Nuno Lopes authored
BoundsChecking: add support for ConstantPointerNull. fixes a bunch of instrumentation failures in loops with reallocs llvm-svn: 158210
-
NAKAMURA Takumi authored
llvm-svn: 158209
-
Filipe Cabecinhas authored
llvm-svn: 158207
-
Hal Finkel authored
The pass itself works well, but the something in the Machine* infrastructure does not understand terminators which define registers. Without the ability to use the block-placement pass, etc. this causes performance regressions (and so is turned off by default). Turning off the analysis turns off the problems with the Machine* infrastructure. llvm-svn: 158206
-
Hal Finkel authored
The code which tests for an induction operation cannot assume that any ADDI instruction will have a register operand because the operand could also be a frame index; for example: %vreg16<def> = ADDI8 <fi#0>, 0; G8RC:%vreg16 llvm-svn: 158205
-
Hal Finkel authored
Add the PPCCTRLoops pass: a PPC machine-code-level optimization pass to form CTR-based loop branching code. This pass is derived from the Hexagon HardwareLoops pass. The only significant enhancement over the Hexagon pass is that PPCCTRLoops will also attempt to delete the replaced add and compare operations if they are no longer otherwise used. Also, invalid preheader DebugLoc is not used. llvm-svn: 158204
-
Alexey Samsonov authored
llvm-svn: 158202
-
Alexey Samsonov authored
llvm-svn: 158201
-
Alexey Samsonov authored
llvm-svn: 158200
-
Duncan Sands authored
can move instructions within the instruction list. If the instruction just happens to be the one the basic block iterator is pointing to, and it is moved to a different basic block, then we get into an infinite loop due to the iterator running off the end of the basic block (for some reason this doesn't fire any assertions). Original commit message: Grab-bag of reassociate tweaks. Unify handling of dead instructions and instructions to reoptimize. Exploit this to more systematically eliminate dead instructions (this isn't very useful in practice but is convenient for analysing some testcase I am working on). No need for WeakVH any more: use an AssertingVH instead. llvm-svn: 158199
-