Open luxaritas opened 6 years ago
Hi. Our tools were originally written without parallelism in mind, so I believe it would be very difficult to safely modify them to perform parallel computation. I am not even sure that LLVM supports concurrent analysis and modifications of LLVM IR by multiple threads.
We are aware that adding parallel processing into RetDec might speed things up. We discussed this several months ago, and decided not to do that, precisely due to the above reason.
Currently, the only way to utilize multiple cores is to run several separate decompilations. This is how we have been using RetDec.
I think the most time-consuming part is the ReachingDefinitionsAnalysis phase and it is used by many translation stage. It can be parallelized by simply using different threads to handle different functions, because the ReachingDefinitionsAnalysis is a kind of intra-procedural analysis.
It looks like a couple steps (namely control flow optimization, constants optimization, and C++ class hierarchy optimization) are bottlenecked by CPU (as opposed to memory). Per #51, everything is currently single threaded, which necessarily creates a bottleneck. For these steps in particular, is it viable to split tasks to be executed across multiple cores?