Golang decompilation ignoring fact xmm15 is always 0?

When analzying Go based samples I’ve noticed that Hex-Rays doesn’t pay attention to the fact that xmm15 is always 0 according to the ABI (see here Go internal ABI specification) . For example, if you have this code:

movq [rsp+0E8h+var_10], xmm15
mov qword ptr [rsp+0E8h+a2], rbx
mov [rsp+0E8h+var_99], 0
movups [rsp+0E8h+var_88], xmm15
movups [rsp+0E8h+var_68], xmm15

then the decompiler will produce this output:

__int128 v2; // xmm15

v23 = (void (**)(void))v2;
v14 = v2;

If xmm15 = 15, then shouldn’t the output be:

v23 = 0;
v14 = 0;

Is there a way to force the decompiler to recognize this? It would clear up some of the VALUE MAY BE UNDEFINED; entries in the decompilation.

In IDA 9.2, the decompiler will know about xmm15 (and other platform-specific zero registers).

is there anyway to make it know with the current version? :slight_smile:

Hm, I guess for now you could make a decompiler plugin which inserts artificial mov #0, xmm15 microinstructions at the start of the functions.