You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Brain dumping about ways to improve runtime performance. The current bottlenecks are most likely:
Expr creation: they require dynamic allocation and are thus costly to create.
Disassembly/Lifting: seems that lifting is actually slower than execution, but I'm not sure whether that could be improved since we are using Sleigh for that
Number class initialisation: if the mpz part has a non-trivial constructor it could hinder the perf gains that we expect from using Number for concrete values
Expr canonisation: currently every expression is canonised upon creation. It certainly induces overhead, especially for memory operations that require using Expr. Computing expression hashes also adds overhead!
Some ideas to address them:
Limit Expr usage as much as possible. Especially, we should not enforce the use of Expr for memory operations and be able to use Number too. Maybe we could consider creating a Value class which would be an std::variant<Expr, Number>
Run some benchmarks/tests to verify this and look into Sleigh to see if perf can be improved. I wonder whether getting the register strings for translating PCODE operands to IR params causes overhead and if there is a way to do the translation without the string comparisons
If mpz has non trivial initialisation, consider wrapping them in a class that enables to skip the init (std::optional maybe?)
Two options:
We could canonise only when needed / when simplifying. The hash could be computed as part of the canonisation.
We could also skip canonisation entirely, but that would suppress some simplifications, and we would have to switch from ExprObject::eq() to comparing Expr raw pointers for quick expression equality (deep expr equality can be done with a recursive method on the arguments...)
The text was updated successfully, but these errors were encountered:
Brain dumping about ways to improve runtime performance. The current bottlenecks are most likely:
Expr
creation: they require dynamic allocation and are thus costly to create.Number
class initialisation: if thempz
part has a non-trivial constructor it could hinder the perf gains that we expect from usingNumber
for concrete valuesExpr
canonisation: currently every expression is canonised upon creation. It certainly induces overhead, especially for memory operations that require usingExpr
. Computing expression hashes also adds overhead!Some ideas to address them:
Expr
usage as much as possible. Especially, we should not enforce the use ofExpr
for memory operations and be able to useNumber
too. Maybe we could consider creating aValue
class which would be anstd::variant<Expr, Number>
mpz
has non trivial initialisation, consider wrapping them in a class that enables to skip the init (std::optional
maybe?)ExprObject::eq()
to comparingExpr
raw pointers for quick expression equality (deep expr equality can be done with a recursive method on the arguments...)The text was updated successfully, but these errors were encountered: