SubfloatFlow causes incorrect decompilation with large constants

[RootCubed]

Describe the bug
The SubfloatFlow rule traverses the operation tree of float2float PcodeOps backwards and converts floating-point constants to the same precision as the float2float output, if I understood correctly. This can cause issues when, for instance, two large floating point numbers are subtracted from each other, resulting in a (relatively) small floating point number which may get rounded down to 0 if the two large numbers are rounded to a smaller floating-point precision format.

Note that I am not asking for this simplification rule to be entirely removed, as it does a good job at keeping the output clean while only slightly reducing the accuracy of the output. But it would be better if this rule were not applied to operations which have only constants as input (since those will be eventually simplified by RuleCollapseConstants, and accuracy can be vital there to having the correct result, see demonstration program)

This issue was first noticed in an instance where the PowerPC int-to-float conversion sequence (https://www.warthman.com/images/IBM_PPC_Compiler_Writer's_Guide-cwg.pdf#G9.303610) was used on a constant value. A simpler example to demonstrate the problem is provided below in the "Additional context" section.

To Reproduce
Steps to reproduce the behavior:

1. Assemble the provided demonstration program.
2. Import it into Ghidra and analyse with default settings.
3. Observe that the decompiler outputs the following:

void demo_float2float_propagate(float *param_1)

{
  *param_1 = 0.0;
  return;
}

Expected behavior
The expected output of the decompiler is:

void demo_float2float_propagate(float *param_1)

{
  *param_1 = 16962.0;
  return;
}

Environment (please complete the following information):

• OS: Windows 11
• Java Version: 17.0
• Ghidra Version: 10.2-DEV
• Ghidra Origin: locally built from master

Additional context

_Z26demo_float2float_propagatePf:
    lis r4, fconst1@h
    ori r4, r4, fconst1@l
    lis r5, fconst2@h
    ori r5, r5, fconst2@l

    # load the two large constants and subtract them
    lfd f1, 0(r4)
    lfd f2, 0(r5)
    fsub f1, f1, f2

    # convert result to 32-bit floating point and store into 0(r3)
    stfs f1, 0(r3)
    blr

fconst1:
# 4503601774871106.0
.long 0x43300000, 0x80004242
fconst2:
# 4503601774854144.0
.long 0x43300000, 0x80000000

demo_compiled.zip

Edit: In order to conform with the floating point conventions of the PowerPC architecture, there should actually be an frsp f1, f1 before the stfs instruction, but since the decompiler output is the same with and without that line, this is irrelevant for this issue.

[RootCubed]

@caheckman This ticket has been on "Internal" status for over a year now - has there been any progress towards a fix for this? Would be greatly appreciated, this bug keeps coming up occasionally "in the wild", messing up the decompiler output.