avast / avast/retdec

DeadLocalAssign is N^3 and doesn't need to be?

Open
#488 2 comments 0 reactions 0 assignees View on GitHub
C-llvmir2hll enhancement P-run
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.