- Mar 01, 2014
-
-
Venkatraman Govindaraju authored
llvm-svn: 202599
-
Venkatraman Govindaraju authored
llvm-svn: 202598
-
Venkatraman Govindaraju authored
llvm-svn: 202597
-
Benjamin Kramer authored
llvm-svn: 202596
-
Sasa Stankovic authored
llvm-svn: 202594
-
Benjamin Kramer authored
No intended functionality change. llvm-svn: 202588
-
Chandler Carruth authored
llvm-svn: 202587
-
Chandler Carruth authored
to the build being C++11. There is clearly still plenty of simplification than can be done here by using standard type traits instead of rolling our own in many places. llvm-svn: 202586
-
Chandler Carruth authored
LLVM_HAS_RVALUE_REFERENCES macro. llvm-svn: 202585
-
Chandler Carruth authored
llvm-svn: 202583
-
Chandler Carruth authored
the core LLVM libraries. llvm-svn: 202582
-
Venkatraman Govindaraju authored
llvm-svn: 202581
-
Chandler Carruth authored
libraries. It is now always 1 in LLVM builds. llvm-svn: 202580
-
Chandler Carruth authored
on unconditionally. Continuing to break down the C++98 support, hopefully without breaking anything. llvm-svn: 202579
-
Venkatraman Govindaraju authored
llvm-svn: 202578
-
Venkatraman Govindaraju authored
llvm-svn: 202577
-
Andrew Trick authored
llvm-svn: 202576
-
Venkatraman Govindaraju authored
llvm-svn: 202575
-
Chandler Carruth authored
on the fact that we now build in C++11 mode with modern compilers. This should flush out any issues. If the build bots are happy with this, I'll GC all the code for coping without R-value references. llvm-svn: 202574
-
Venkatraman Govindaraju authored
llvm-svn: 202573
-
Venkatraman Govindaraju authored
llvm-svn: 202572
-
Venkatraman Govindaraju authored
llvm-svn: 202571
-
Mark Seaborn authored
lib/Support/RWMutex.cpp contains an implementation of RWMutex that uses pthread_rwlock, but when pthread_rwlock is not available (such as under NaCl, when using newlib), it silently falls back to using the no-op definition in lib/Support/Unix/RWMutex.inc, which is not thread-safe. Fix this case to be thread-safe by using a normal mutex. Differential Revision: http://llvm-reviews.chandlerc.com/D2892 llvm-svn: 202570
-
Chandler Carruth authored
baseline is now C++11, and we unconditionally add -std=c++11 to the flags. This has the dim potential to break some non-GNU-compatible compiler (in terms of -std flags) using the makefiles, but those makefiles are littered with GNU-style compile flags so it would be very surprising to me for it to actually happen in practice. As always, do let me know if there is a toolchain you're using where this doesn't work, and I'll be watching the bots. llvm-svn: 202569
-
Chandler Carruth authored
LLVM_ENABLE_CXX1Y (default *off*). =D C++98 is dead. Long live C++11. I don't exactly recommend using C++1y just yet though... llvm-svn: 202567
-
Chandler Carruth authored
The switch has been thrown. While I'm still watching for any failures or problems with this, the documentation can go ahead and move forward. llvm-svn: 202566
-
Venkatraman Govindaraju authored
llvm-svn: 202565
-
Venkatraman Govindaraju authored
llvm-svn: 202564
-
Venkatraman Govindaraju authored
[Sparc] Emit 'restore' instead of 'restore %g0, %g0, %g0'. This improves the readability of the generated code. llvm-svn: 202563
-
Manman Ren authored
Inside iterate, we scan backwards then scan forwards in a loop. When iteration is not zero, the last node was just updated so we can skip it. But when iteration is zero, we can't skip the last node. For the testing case, fixing this will save a spill and move register copies from hot path to cold path. llvm-svn: 202557
-
- Feb 28, 2014
-
-
Reid Kleckner authored
Patch by Jevin Sweval! llvm-svn: 202556
-
Reid Kleckner authored
llvm-svn: 202555
-
Lang Hames authored
Reverting until the C++11 switch is complete. llvm-svn: 202554
-
Lang Hames authored
The previous PBQP solver was very robust but consumed a lot of memory, performed a lot of redundant computation, and contained some unnecessarily tight coupling that prevented experimentation with novel solution techniques. This new solver is an attempt to address these shortcomings. Important/interesting changes: 1) The domain-independent PBQP solver class, HeuristicSolverImpl, is gone. It is replaced by a register allocation specific solver, PBQP::RegAlloc::Solver (see RegAllocSolver.h). The optimal reduction rules and the backpropagation algorithm have been extracted into stand-alone functions (see ReductionRules.h), which can be used to build domain specific PBQP solvers. This provides many more opportunities for domain-specific knowledge to inform the PBQP solvers' decisions. In theory this should allow us to generate better solutions. In practice, we can at least test out ideas now. As a side benefit, I believe the new solver is more readable than the old one. 2) The solver type is now a template parameter of the PBQP graph. This allows the graph to notify the solver of any modifications made (e.g. by domain independent rules) without the overhead of a virtual call. It also allows the solver to supply policy information to the graph (see below). 3) Significantly reduced memory overhead. Memory management policy is now an explicit property of the PBQP graph (via the CostAllocator typedef on the graph's solver template argument). Because PBQP graphs for register allocation tend to contain many redundant instances of single values (E.g. the value representing an interference constraint between GPRs), the new RASolver class uses a uniquing scheme. This massively reduces memory consumption for large register allocation problems. For example, looking at the largest interference graph in each of the SPEC2006 benchmarks (the largest graph will always set the memory consumption high-water mark for PBQP), the average memory reduction for the PBQP costs was 400x. That's times, not percent. The highest was 1400x. Yikes. So - this is fixed. "PBQP: No longer feasting upon every last byte of your RAM". Minor details: - Fully C++11'd. Never copy-construct another vector/matrix! - Cute tricks with cost metadata: Metadata that is derived solely from cost matrices/vectors is attached directly to the cost instances themselves. That way if you unique the costs you never have to recompute the metadata. 400x less memory means 400x less cost metadata (re)computation. Special thanks to Arnaud de Grandmaison, who has been the source of much encouragement, and of many very useful test cases. This new solver forms the basis for future work, of which there's plenty to do. I will be adding TODO notes shortly. - Lang. llvm-svn: 202551
-
Chandler Carruth authored
bots when using the standard library facilities. The missing pieces here aren't always in useful discreet chunks. Fortunately, the missing pieces are few and far between, and we can emulate most of them in our headers as needed. Based on feedback from Lang and Dave. llvm-svn: 202548
-
Chandler Carruth authored
systems have the default as C++11, but retain the ability to build with C++98. Again, please restrain your enthusiasm a bit in case this needs to be reverted. =] llvm-svn: 202546
-
Eric Christopher authored
llvm-svn: 202545
-
Tom Stellard authored
Make a call to R600's implementation of verifyInstruction() to check that instructions are only using legal operands. llvm-svn: 202544
-
Tom Stellard authored
llvm-svn: 202543
-
Chandler Carruth authored
Now, please don't get too excited. I've just toggled the default to suss out the last remaining bot problems. This does *not* mean we can all go write lots of C++11 code yet. I at least want to let the dust settle from the bots first. llvm-svn: 202542
-