From f2c603a4994d4e12e97c7fcd1f910798b19ffa71 Mon Sep 17 00:00:00 2001 From: LagoLunatic Date: Tue, 29 Apr 2025 15:54:37 -0400 Subject: [PATCH] Mention `ninja changes` in regalloc tutorial --- docs/decompiling.md | 2 +- docs/regalloc.md | 6 ++++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/decompiling.md b/docs/decompiling.md index 51a6aa55c..e99f0a4d6 100644 --- a/docs/decompiling.md +++ b/docs/decompiling.md @@ -159,7 +159,7 @@ The macro to use in this case is `JUT_ASSERT`, which handles checking a conditio JUT_ASSERT(0x181, modelData != NULL); ``` -Note that any variables used in a debug assertion must have their names match the assertion string exactly, like the `modelData` local variable in this case. This can sometimes even give you the official name of a member variable. Defines like `NULL` or `FALSE` work a bit differently and show up as their value (zero) in the assertion strings, instead of appearing the way the programmer actually wrote them. +Note that any variables used in a debug assertion must have their names match the assertion string exactly, like the `modelData` local variable in this case. This can sometimes even give you the official name of a member variable. Defines like `NULL` or `FALSE` work a bit differently and show up as their value (e.g. `0`) in the assertion strings, instead of appearing the way the programmer actually wrote them. Other than those two macros, there's another common case that can cause code to look very different in Ghidra compared to how it was originally written: **inline functions**. These are used all over the place in TWW's codebase, and they're important to get right for several reasons, but as there are thousands of them we can't go over all of them individually in this guide. Instead, let's go over what the workflow for finding them on your own will look like. diff --git a/docs/regalloc.md b/docs/regalloc.md index 7ea687e57..c0115db62 100644 --- a/docs/regalloc.md +++ b/docs/regalloc.md @@ -112,7 +112,9 @@ Sometimes, instead of writing a single line that does multiple things at once, y Inlines can affect regalloc, so be sure that you're using the exact inlines mentioned in the debug maps. Also try using inlines used in other functions from the same object, or inlines used in similar functions from a different object. -If you're sure that you're using the right inline, but there are still regswaps happening in the area of the function where the inline is used, the cause can sometimes be that the inline itself is implemented wrong. You may have to try modifying the inline and write the code inside it differently in order to fix the regalloc in the functions that use it. But when doing this, be careful that you don't break any already-matched functions that use the same inline you're modifying. +If you're sure that you're using the right inline, but there are still regswaps happening in the area of the function where the inline is used, the cause can sometimes be that the inline itself is implemented wrong. You may have to try modifying the inline and write the code inside it differently in order to fix the regalloc in the functions that use it. + +But when modifying an existing inline, be careful that you don't break any already-matched functions that use the same inline. If you want to quickly check if you caused any regressions, first run `ninja baseline` on the main branch, then run `ninja changes` on your own branch, and any functions that decreased in match percent on your branch will be printed out. ## Const @@ -132,4 +134,4 @@ However, `f32` is a primitive type. So the following is another possibility for TVec3(const f32 x, const f32 y, const f32 z) ``` -You may need to try adding or removing const from inlines like this, but be careful that you don't break any already-matched functions that use the same inline you're modifying. +You may need to try adding or removing const from inlines like this, but be careful that you don't break any already-matched functions that use the same inline you're modifying. Again, you can use `ninja changes` to check if you caused any regressions.