New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IR Optimization #123
Comments
The following is what the prologue of createStatements in X86InstructionAnalyzer looks like with this added:
` |
On Tue, Apr 04, 2017 at 09:03:05AM -0700, chrisps wrote:
Is this a good idea, or would you prefer it be implemented a different
way?
These transformations do not depend on the architecture, so, I would not
implement them in InstructionAnalyzer. Probably, I would put them in a
separate pass over IR, for example, next after the MasterAnalyzer::
createProgram() call in MasterAnalyzer::decompile().
You might want to use a basic-block-level dataflow analysis, to discover
which register is defined where, without searching manually. There is an
example of how to do it in IRGenerator::computeJumpTargets().
…--
Yegor Derevenets
|
Probably you will benefit from reading nc/core/ir/misc/PatternRecognition.cpp — you might want to implement a function similar to those in that file, called, e.g., recognizeMultiplicationByConstant(). Once you have this function, you could also change recognizeArrayAccess() to use it. |
Thank you for the information, it can be a little difficult figuring out the best way to do these things sometimes when you're not familiar with the code. I'll try adding something after decompile() |
Consider this assembly code:
41b00f: lea eax, [edx*4+0x0] 41b016: sub eax, edx 41b018: add eax, eax 41b01a: mov edx, eax 41b01c: shl eax, 0x3 41b01f: add edx, eax
Which translates to:
(edx10 * 4 - edx10) * 2 + (edx10 * 4 - edx10) * 2 * 8)
but is actually a multiplication by 54
We can fold this in the LikeC tree, but struct members and global variable types are determined prior to tree generation from what I can tell. So I wrote up some proof-of-concept code for analyzing preceding IR statements in the current basic block and merging them. Is this a good idea, or would you prefer it be implemented a different way?
The text was updated successfully, but these errors were encountered: