VBCC backend generates unnecessary register assignments (even when using -O3)

[sy2002]

Possibly a challenge in the backend (c/qnice/compiler-backend/machine.c). Volker said that it is not trivial. I am creating this issue, so that we are not forgetting about it. Right now, we can for sure live with it. But we are wasting 4 CPU cycles (or more) in certain function calls in C, for example in Monitor wrapper functions.

---

Here is the email I wrote to Volker on October, 28 2020:

[...]

qmon is a wrapper library, that wraps our "Operating System" functions.

For example this here calls the OS function "mulu" that takes two 16bit unsigned values and returns a 32bit signed value:

unsigned long def_qmon_mulu(unsigned int a, unsigned int b) =
  "          ASUB     " M2S(QMON_EP_MULU) ", 1\n"           //call MTH$MULU in monitor (expects a in R8, b in R9)
  "          MOVE     R10, R8\n"                            //R10 = low word
  "          MOVE     R11, R9\n";                           //R11 = high word

unsigned long qmon_mulu(unsigned int a, unsigned int b)
{
    return def_qmon_mulu(a, b);
}

The library code, is compiled with these switches and looks like this:

vc src/qmon.c -o lib/qmon.o -c -O3 -k -c99 -rw-threshold=0 -speed

_qmon_mulu:
	incrb
	move	R8,R0
	move	R9,R10
	move	R0,R8
	move	R10,R9
          ASUB     0x0028, 1
          MOVE     R10, R8
          MOVE     R11, R9

	decrb
	move	@R13++,R15

Note the redundant

MOVE R8, R0 
MOVE R0, R8

and

MOVE R9, R10
MOVE R10, R9

statements.

Is this an easy or hard fix?

This is not a big deal, so we for sure can live with it for the time being. Particularly, if this is due to some structural challenges or if fixing this might lead to an increased danger of regressions.

---

Here is his answer:

[...]

It is not easy enough to make any promises unfortunately.