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
It looks like the contents of the table need to be sorted according to its
value, so that the runtime can find the entry by binary search. I'm not 100%
sure if we really have to do that, but at least I can say it's safe to do
because the contents of .sxdata is just a list of exception handlers' RVAs.
llvm-svn: 202550
This seems a little more straightforward and is equivalent to r201457
for ELF core files. A case for FreeBSD i386 is also added (it was
incorrectly using the 64-bit register context and corrupting mememory).
Better (user-facing) error handling is still needed.
Review: http://llvm-reviews.chandlerc.com/D2765
llvm-svn: 202549
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
This change adds a missing include path to the
ObjC LanguageRuntime path to the MacOSX SystemRuntime
plugin's Makefile.
It also adds the panel and curses library to the liblldb
shared library linkage step.
Changes by Jevin Sweval with a minor tweak.
llvm-svn: 202547
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
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
during the finalization for CGDebugInfo in clang we would RAUW
a type and it would result in a corrupted MDNode for an
imported declaration.
Testcase pending as reducing has been difficult.
llvm-svn: 202540
Was r202442
There were two issues with the original patch that have now been fixed.
1. We were memset'ing over a FileEntry in a test case. After adding a
std::string to FileEntry, this still happened to not break for me.
2. I didn't pass the FileManager into the new compiler instance in
compileModule. This was hidden in some cases by the fact I didn't
clear the module cache in the test.
Also, I changed the copy constructor for FileEntry, which was memcpy'ing
in a (now) unsafe way.
llvm-svn: 202539
Tools that use the CommandLine library currently exit with an error
when invoked with -version or -help. This is unusual and non-standard,
so we'll fix them to exit successfully instead.
I don't expect that anyone relies on the current behaviour, so this
should be a fairly safe change.
llvm-svn: 202530
I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion.
<rdar://problem/16111293>
llvm-svn: 202525
I suspect I may have misrun the test previously for check-in
r202456 re: pr15258. This test fails consistently on my end.
I changed the test to expected failure on Linux.
llvm-svn: 202517
TestRegisterVariables.test_with_dwarf_and_run_command was being
skipped on Linux due to issues with clang. I converted it to a
@expectedFailureClang and no longer skip on Linux.
llvm-svn: 202515
TestConstVariables.py was disabled on Linux and marked as
unconditional expected failure. This change removes the Linux disable
and makes the expected failure conditional on using clang. The test
runs fine on gcc-built lldb.
llvm-svn: 202514
This test passed 50 out of 50 times for me on Unbuntu 12.04 LTS x86_64
with lldb built using gcc 4.8.2 and July 2013 libedit.
This is related to:
http://llvm.org/bugs/show_bug.cgi?id=16170
llvm-svn: 202512
Related to this bug:
http://llvm.org/bugs/show_bug.cgi?id=16714
On TOT lldb svn r202507, I found several of the tests disabled within
TestConcurrentEvents.py to run fine, and several of them to fail 100%
of the time on my system (25 out of 25 times).
This changes the following tests for Linux:
Enables (these all work consistently):
* test_many_watchpoints_dwarf
* test_signal_watch_break_dwarf (line 250)
* test_signal_watch_break_dwarf (line 260 - same named test?)
* test_crash_with_watchpoint_dwarf
* test_crash_with_watchpoint_breakpoint_signal_dwarf
* test_delayed_crash_with_breakpoint_watchpoint_dwarf
Marks as expected failure (these all fail consistently):
* test_many_watchpoints_dwarf
* test_watch_break_dwarf
* test_delay_watch_break_dwarf
* test_watch_break_dwarf_delay
* test_signal_watch_dwarf
* test_delay_signal_watch_dwarf
* test_signal_delay_watch_dwarf
* test_two_breakpoints_one_watchpoint_dwarf
* test_breakpoints_delayed_breakpoint_one_watchpoint_dwarf
* test_two_watchpoint_threads_dwarf
* test_watchpoint_with_delay_watchpoint_threads_dwarf
* test_two_watchpoints_one_breakpoint_dwarf
* test_two_watchpoints_one_delay_breakpoint_dwarf
* test_watchpoint_delay_watchpoint_one_breakpoint_dwarf
* test_two_watchpoints_one_signal_dwarf
* test_signal_watch_break_dwarf
llvm-svn: 202511
Related to this bug:
http://llvm.org/bugs/show_bug.cgi?id=15037
Previously this was marked as skipped. I tried running it 10 times in
a row and it failed every time. Switched it to XFAIL.
llvm-svn: 202506
Lang Hames