It sounds like you know how to use Hex-Rays to a non-trivial extent. You have probably noticed that Hex-Rays might -- or might not -- pause noticeably when decompiling a large function that you have already decompiled some time ago. That's because Hex-Rays often decompiles the same function more than once -- numerous times, actually -- throughout the course of the user's analysis session.
The past few versions of Hex-Rays have introduced caches for the decompilation results, particularly the mba_t
and cfunc_t
structures from the SDK, to speed up displaying decompilation for functions that have recently been analyzed. That said, these are just caches; they can be evicted for reasons such as the user changing the type of a function or global data item used by the cached function. Regardless of caches, Hex-Rays will still re-analyze previously seen functions sometimes. Additionally, the user can also shrink their database by manually purging all caches via Edit->Other->Reset decompiler information...
, the All caches
checkbox.
Regardless of caches, Hex-Rays, of course, wants to save all of the local variable names, types, and locations; union selections; label names; number formats; comments; mapped variables; forced variables; split assignments; user-defined calls; manually forced prototypes for indirect calls; and so on that the user created while annotating a function. This information is stored in the database, such that even if Hex-Rays does not have a cache entry for a function, and hence must decompile it "from scratch", it will still incorporate the user's saved analysis annotations into the decompilation process. This is much like the ordinary disassembly listing; all user annotations are saved in the database, such that even if you open the IDB in a more recent version, you will still see your previous annotations.
There's only one element of Hex-Rays analysis (that I'm aware of) that will be carried over from older versions when upgrading your IDB to a newer version. In particular, after Hex-Rays has analyzed a function, it saves the results of local variable allocation in the database. That means that if you created a database with an older version of Hex-Rays, and the newer version would have performed better analysis of the local variables with more pleasing results, you won't benefit from those upgrades when upgrading to a newer version. So it goes.
TL;DR: you can upgrade a database in which you previously performed analysis in Hex-Rays, and you will see all of your modifications to the pseudocode. I do this all the time. You will be able to use any new features that Hex-Rays has introduced in the meantime. To the extent that any new auto-analysis capabilities are run automatically when decompiling a function, you will benefit from those, too. Only a few aspects of the automated analysis from the prior version will remain in the upgraded database (as opposed to the manual annotations, of which all shall remain); the rest of them will be performed afresh upon cache eviction of the function in question. You can purge all caches using the menu item described in the second paragraph, which will force all functions to be decompiled afresh.