Some modification will be surely merged but free time is very scarce
AIO isn't important. It would be very easy to replace it with a standard IO.
Hehe, free time is precious, indeed. Going through the code and also glancing at the current progress with the OSX side of things: a lot of functionality that comes now into the codebase (e.g. threading) is again very OS-dependent so soon you would have "Mac" folders next to the "Linux" and "Windows" ones. Going trough them I see that there is a lot of code that revolves around file access, mmaps, threading and the usual things that libraries like Boost are perfect in handling. I don't know the team's stance on this (and I am not a preacher of Boost or anything) but wouldn't the inclusion of such a library have its best time now? Just before everything becomes more portable and arch-/platform-independent? A lot of those files in the "Linux" and "Windows" folders now use OS-dependent two-liners. I would like to help here since I regard this as a fundamental thing to push pcsx2 forward towards that goal. I could start from Linux 32-bit builds and remove the "Linux" and "Windows" folders with equivalent Boost (or any other lib) functionality in the commons-part. First the easy things that are unlikely to brake stuff (like file access etc.) and removing AIO in the process as well. What are you/the team thinking?
From an old PCSX2 dev:
http://forums.pcsx2.net/Thread-blog-C-ex...5#pid79305
On my side, I'm afraid of packaging issue (32 bits compilation on 64 bits, new library transition) + additional compilation time. Honestly I'm not sure the boost big bertha is the best solution. I would ask others opinions.
Note AIO is just a minor optimization. It might even work without any implementation.
By the way it is still possible to use portable code only for OSX. And later extend it to others OS if it is fine.
I think the best solution for now is to wait until all the important 64bit-changes have been done. Since you port it and there are two other guys hitting at an OSX version I will just wait until the branches converge more or less. I guess it makes no sense to open up another keg. Then I would definitely chime in again.
On
https://github.com/PCSX2/pcsx2/blob/mast...eLists.txt why are the optimizations flags separated like that. That's almost -02 for gcc
-fauto-inc-dec
-fcompare-elim
-fcprop-registers
-fdce
-fdefer-pop
-fdelayed-branch
-fdse
-fguess-branch-probability
-fif-conversion2
-fif-conversion
-fipa-pure-const
-fipa-profile
-fipa-reference
-fmerge-constants
-fsplit-wide-types
-ftree-bit-ccp
-ftree-builtin-call-dce
-ftree-ccp
-ftree-ch
-ftree-copyrename
-ftree-dce
-ftree-dominator-opts
-ftree-dse
-ftree-forwprop
-ftree-fre
-ftree-phiprop
-ftree-sra
-ftree-pta
-ftree-ter
-funit-at-a-time
-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging.
-O2
Optimize even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff. As compared to -O, this option increases both compilation time and the performance of the generated code.
-O2 turns on all optimization flags specified by -O. It also turns on the following optimization flags:
-fthread-jumps
-falign-functions -falign-jumps
-falign-loops -falign-labels
-fcaller-saves
-fcrossjumping
-fcse-follow-jumps -fcse-skip-blocks
-fdelete-null-pointer-checks
-fdevirtualize
-fexpensive-optimizations
-fgcse -fgcse-lm
-finline-small-functions
-findirect-inlining
-fipa-sra
-foptimize-sibling-calls
-fpartial-inlining
-fpeephole2
-fregmove
-freorder-blocks -freorder-functions
-frerun-cse-after-loop
-fsched-interblock -fsched-spec
-fschedule-insns -fschedule-insns2
-fstrict-aliasing -fstrict-overflow
-ftree-switch-conversion -ftree-tail-merge
-ftree-pre
-ftree-vrp
Coudn't we just define -02 ? Or at least enable some inline functionality that currently its not defined?
A long time ago, PCSX2 wasn't stable with all gdb optimization. So O2 was replaced with nearly all optimization minus a couple one.
I'm very close to get back to O2 again. However it would help a lots if someone find optimization that are not activated.
1/ Either flags are replaced with 02 + -fno-... flags
2/ Either we completely swtich to 02 (minus the fact that a couple of flags are disabled like strict aliasing).
Others cmake files that are impacted
Quote:https://github.com/PCSX2/pcsx2/blob/mast...eLists.txt
https://github.com/PCSX2/pcsx2/blob/mast...eLists.txt
-finline-small-functions
-findirect-inlining
-fpartial-inlining
Namely those are missing.
I would opt for 1) i guess Clang would be happier as well
Actually maybe it will be safe to enable O2 instead. I don't think inline could break code, actually it might fix some compilation issue (failed to inline some functions).
For coverity, I will discuss with some friends that use it. However I'm afraid that is pretty expensive and last but not least that it requires a test suite.