Propagate discovered constants from comparisons in decompiler

[dt-12345]

Is your feature request related to a problem? Please describe.
Sometimes, you may have a function like this

int bar();

int foo(void* ptr) {
    if (ptr == nullptr)
        return 0;
    return bar();
}

which does a null check on a pointer and returns 0/false if it's null. If the pointer exists in the return value register, the compiler will usually just return the pointer directly. This can result in ugly decompilation where the pointer's type is propagated to all return values (or vice versa resulting in subpieces of the pointer instead).

Describe the solution you'd like
In the case where an equality comparison against a constant occurs, creating a new constant for the success branch to replace the original value and propagating it may result in better decompilation. I'm not super familiar with the decompiler internals so I don't know how this would be implemented specifically or if something similar is already being done.

Describe alternatives you've considered
It's functional as is, but this would be a nice quality-of-life improvement as it'd improve data type analysis in larger functions where this occurs.

[mumbel]

#4527

Made a similar request, but forgot to follow up

[caheckman]

I'm not reproducing this. The decompiler already propagates constant values conditionally. For the first example, I am getting

int foo(void *param_1)

{
  int iVar1;
  
  if (param_1 != (void *)0x0) {
    iVar1 = bar();
    return iVar1;
  }
  return 0;
}

where the null/zero value propagates conditionally to the return statement.

Can you provide a "Debug Function Decompilation" output file here for one of these functions (the action is in the drop down menu in the upper right corner of the decompiler window) and post it here with the version of Ghidra you are using?

[dt-12345]

Sure, here's the output for the two examples above: decompilation.zip
I'm using the latest 11.4.1 release, interesting that it works for you. I've been testing on AArch64 mostly so perhaps the architecture makes a difference?

[dt-12345]

Ah, I think it is an architecture difference. I just tested the example I had on x86 and it works properly:

[LukeSerne]

It makes sense that the x86 version has the decompiler outputting return 0;, since the compiler emitted an xor eax, eax instruction to explicitly set the return value to 0 instead of moving the input register (rdi) into eax.

On AArch64, the first argument (x0) is stored in the same register as the return value (w0), so the compiler can directly emit a return instruction after determining that the input is 0 / nullptr. On x86, the known-zero register is a different register than the register containing the return value, so an extra instruction is always needed.

[CreepNT]

I don't have an example on hand but this is definitely a pattern I've seen a lot on ARMv7-A binaries too.

Edit: example n°1 of a similar but reverse situation

Corresponding ASM:

int PhyMemPartInitWoSegmentRaw(SceKernelPhyMemPart *pPMP):
    push       {r3,r4,r5,r6,r7,lr}
    mov        r5,r0
    ldr        r0,[r0,#0x7c]
    movw       r1,#0x7aa0
    mov        r2,lr
    movt       r1=>kmc_51037aa0,#0x5103
    add.w      r7,r5,#0x84
    add.w      r6,r5,#0x88
    adds       r0,#0x0
    it         ne
    mov.ne     r0,#0x1
    bl         sceKernelAssert     void sceKernelAssert(bool expr, kmc *ctx)