#4234 PIC16 optimize-df can incorrectly drop FSR0H across calls and returns

[zeynelsagcan]

While debugging PIC16 64-bit code-generation failures, I found an issue in the PIC16 data-flow defmap handling in src/pic16/pcode.c.

FSR0L is modeled across calls and returns, but FSR0H is missing from the corresponding defmap entries.

This can make --optimize-df treat the high byte of FSR0 as dead and remove code that is still required to preserve or restore the complete FSR0 pointer.

The relevant code already handles FSR0L, for example:

list = newDefmap (SPO_FSR0L, 0xff, 0xff, 1, 1, pc, newValnum (), list);

but the matching FSR0H entry is absent.

The proposed fix adds SPO_FSR0H alongside SPO_FSR0L in the three relevant call/return cases:

list = newDefmap (SPO_FSR0H, 0xff, 0xff, 1, 1, pc, newValnum (), list);

and for the return-side pseudo-read cases:

list = newDefmap (SPO_FSR0H, 0xff, 0x00, 1, 0, pc, 0, list);

I reproduced the problem with small PIC16 test cases involving values that require the full FSR0 pointer and verified that the generated code is correct after the change.

The attached patch contains only the PIC16 defmap fix:

pic16_fsr0h_defmap.patch

The patch is based on revision r17065 and applies cleanly to a pristine r17065 checkout.