DeadLocalAssign is N^3 and doesn't need to be?
- Dominant language
- C++
- Stars
- 8.6k
- Forks
- 1k
- PR merge metrics
- No merged PRs in 30d
Description
I've worked on optimizers for many years in LLVM and GCC, but am new to retdec, so maybe I am missing something.
I am looking at speeding up retdec on large binaries, with the two easiest targets being copyprop and deadlocalassign.
Looking at dead local assignment, it iterates until the code stops changing.
On each iteration, it walks all local variables.
For each local variable, it walks all uses.
This is of course, N^3.
I started fixing this to make it O(N) by inverting the logic[1].
I then realized the entire optimization doesn't need to iterate at all.
As far as i can see, none of the things in canBeOptimized can ever be changed by another change the optimization will make. Most address the specific local variable in question. Those will not change if the optimization removes things related to some other variable.
Arguably the read variables could change but that would be a sign that AA is very poor.
What am I missing?
To check my theory, changing the optimization to not iterate and running it on some very large testcases I have, the IR before and after the optimization did not change.
Assuming i'm right, i'll send a patch.
[1] Assuming DCE of some sort has been run, it's faster to process statements and mark which are variable defining/have function calls, which disqualify those variables. You can also which variables are disqualified because canBeOptimized can easily just be applied per-statement for the variables that exist in the statement.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by locating the deadlocalassign optimization and inspect canBeOptimized, then compare the current iterative behavior with the proposed single-pass approach. Validate the result on large test cases by checking that the IR before and after optimization is unchanged while measuring whether the work scales better.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- compilers, performance
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100