These upcoming updates primarily help users working close to the metal, on kernels, firmware, and embedded targets, where stack behavior and control flow need to be trustworthy.
By improving instruction decoding, idiom recognition, and cross-reference generation, these changes turn previously noisy or ambiguous regions of code into something that can be analyzed directly.
When released, IDA 9.3 improves decoding of Scalable Vector Extension (SVE) and Scalable Matrix Extension (SME) instructions as used in recent Apple kernels.
STR Z0, [X2]
STR Z1, [X2,#1,MUL VL]
STR Z2, [X2,#2,MUL VL]
STR Z3, [X2,#3,MUL VL]
UZP1 V0.4S, V0.4S, V1.4S
ZIP1 V2.4S, V2.4S, V2.4S
Concretely:
The ARM64 decompiler now emits explicit intrinsics for Memory Tagging Extension instructions instead of inline assembly blocks. Instructions such as IRG, ADDG, GMI, LDG, STG, and SUBP are translated into corresponding __arm_mte_* intrinsics in the decompiler output.
Before:
__int64 __fastcall create_tag(__int64 _X0, unsigned int a2)
{
__int64 result; // x0
_X8 = a2;
__asm { IRG X0, X0, X8 }
return result;
}
After:
void *__fastcall create_tag(void *a1, unsigned int a2)
{
return __arm_mte_create_random_tag(a1, a2);
}
See the release notes for a full list of supported MTE intrinsics: https://docs.hex-rays.com/release-notes/9_3beta#memory-tagging-extension-mte-intrinsics
We added decoding and decompiler support for ARMv8 CSSC instructions, including SMAX, SMIN, UMAX, UMIN, ABS, CNT, and CTZ. For scalar general-purpose register variants, the decompiler also emits corresponding intrinsics, improving readability and reducing noise in arithmetic-heavy code paths.
ABS W0, W0
CNT W21, W10
CTZ W23, W13
SMAX WZR, WZR, #0xFFFFFFFF
SMIN X0, X0, #0
UMAX XZR, XZR, #0xFFFFFFFFFFFFFFFF
UMIN X23, X13, X8
Address construction using MOV/MOVK (AArch64) and MOVW/MOVT (ARM/Thumb) sequences is now handled more robustly, including cases where instructions are not strictly adjacent.
Before
MOV X8, #0
MOV W9, #0x64AE
MOVK X8, #0,LSL#16
MOVK W9, #0x299E,LSL#16
MOVK X8, #0,LSL#32
MOVK X8, #0,LSL#48
After
MOV X8, #(WORD0(unk_16120))
MOV W9, #(WORD0(0x299E64AE))
MOVK X8, #(WORD1(unk_16120)),LSL#16
MOVK W9, #(WORD1(0x299E64AE)),LSL#16
MOVK X8, #(WORD2(unk_16120)),LSL#32
MOVK X8, #(WORD3(unk_16120)),LSL#48
At the same time we added support for AArch64 MOVW_UABS_G[0-3] relocations, allowing ELF binaries that build addresses via MOVZ/MOVK sequences to produce correct references for each 16-bit chunk and, where applicable, merged full-width addresses.
On Apple platforms, recognition of __auth_stubs sections has improved, and BTI-enabled PLT stubs in ELF binaries are now correctly detected, named, and marked as thunks.
We’re introducing a new processor module for the Andes AndeStar™ V3 NDS32 architecture, along with ELF loader integration. NDS32 ELF binaries are now recognized automatically, with IDA selecting the correct processor and displaying architecture and ABI details directly in the load banner.
It supports NDS32’s mixed 16-bit and 32-bit instruction encodings, covering the base ISA along with commonly used extensions such as DSP, SIMD, ZOL, FPU, and coprocessor instructions. For better readability, by default IDA hides the encoding suffixes of instruction mnemonics (i.e. movi rather than movi55, add rather than add333, etc.) and the dollar prefixes of registers. If needed, these details can be enabled again in the processor module options.
Concretely:
IDA 9.3 improves ARC disassembly by recognizing common stack save and restore idioms and presenting them as explicit push and pop instructions. Store and load instructions that update the stack pointer by one word are now rewritten when they semantically represent a push or pop.
Before
st.a r16, [sp,0xC+var_10]
st.a r17, [sp,0x10+var_14]
st.a r18, [sp,0x14+var_18]
st.a r19, [sp,0x18+var_1C]
st.a r20, [sp,0x1C+var_20]
st.a r21, [sp,0x20+var_24]
st.a fp, [sp,0x24+var_28]
After
push r16
push r17
push r18
push r19
push r20
push r21
push fp
Because pushes and pops are now explicit, IDA’s stack tracking logic can reason about ARC functions more reliably. Stack pointer deltas are derived directly from push/pop instructions, which leads to more consistent stack point placement and frame sizing.
This also preserves compatibility with existing ARC analysis features. In particular, ARCompact millicode patterns that rely on recognizing chains of push instructions continue to be detected correctly, even with instruction simplification enabled.
These changes are also reflected in the decompiler.
Both the RISC-V disassembler and the decompiler now support the Andes XAndesPerf extension (29 new instructions). We’ve also added processor specific options for vendor extensions (currently Andes XAndesPerf and T-Head XThead). You can toggle those extensions in the RISC-V specific options dialog.
When only Andes decoding is enabled, those words disassemble as nds.* instructions; with only T-Head enabled, they disassemble as th.*. If you’d rather not have these prefixes, you can enable the “Hide extension prefixes” option.
If both vendor extensions are enabled and an encoding collides, the procmod doesn’t silently choose one interpretation: it keeps one as the primary decode and emits the other as an auto-comment (for example: nds.lbgp a0, 11BC5h ; alt XThead: th.lrb). That makes ambiguity explicit during analysis, which is especially helpful when you’re dealing with incomplete core documentation or binaries built for slightly different configurations.
IDA 9.3 includes a set of focused analysis improvements for TriCore that mainly affect how values are tracked and how control flow is reconstructed. You can now use the regfinder API programmatically:
import ida_idp
import ida_regfinder
reg = ida_idp.str2reg(reg)
res = ida_regfinder.find_reg_value(ea, reg)
Switch statement detection has also been refined, allowing more jump tables to be recognized and rendered as structured control flow instead of opaque indirect branches.
Taken together, these changes make disassembly more trustworthy and analysis workflows more predictable. As always, feedback from real binaries is invaluable, particularly for edge cases that still don’t decode or analyze as expected.