Llvm36: Code fix and perf improvement #1193
Conversation
|
Fixed an issue with address not being divised by 4 where it should, spotted by flashmozz |
| @@ -289,12 +289,20 @@ RecompilationEngine::RecompilationEngine() | |||
| , m_currentId(0) | |||
| , m_last_cache_clear_time(std::chrono::high_resolution_clock::now()) | |||
| , m_compiler(*this, CPUHybridDecoderRecompiler::ExecuteFunction, CPUHybridDecoderRecompiler::ExecuteTillReturn, CPUHybridDecoderRecompiler::PollStatus) { | |||
|
|
|||
| // PS3 has 256 Mb of memory. | |||
There was a problem hiding this comment.
Totally unrelated. Yes, PS3 has something about 256+256 MB of physical memory. But we don't emulate physical memory, we emulate virtual memory which overall range is assumed to be 4 GB.
Here is 512 MB of the host memory allocated, which is quite a big amount, since most of it will be unused anyway. It approximately doubles rpcs3 memory consumption.
vlj
force-pushed
the
llvm36
branch
5 times, most recently
from
61f903c
to
211235d
Compare
|
Rebased + I use virtualAlloc/mmap to allocate the table. I factored the calls in 3 functions in vm namespace. |
|
No, not in vm namespace. Not a good idea. |
|
Moved to Utilities |
vlj
force-pushed
the
llvm36
branch
3 times, most recently
from
0b125d0
to
610d68a
Compare
|
Use a namespace, and tweaked reservation size + added some comments/define |
vlj
force-pushed
the
llvm36
branch
2 times, most recently
from
82ecce4
to
0ca907d
Compare
…ion result. The hashmap overhead may be really big in some case.
|
Fixed typo and added comments |
|
LGTM |
This PR makes some a little clearer and also make it more efficient by avoiding uneeded indirection and by adding a big table.