Incorrect codegen somewhere around inline assembly about llvm-mos

[mysterymath]

Managed to track this one down; as part of making use of the zero page, the compiler looks for callee-saved imaginary registers and re-writes them to zero page locations that are unique to the function they are used in. This elides the push and pop of those registers to the stack at the beginning and end of the function.

This is done very late, as instructions that use those opcodes are being lowered into the assembler part of the backend. Inline assembly is handled elsewhere, so this translation was missed. It should be fine to do it there too; anything that uses an imaginary register can use a different zero page location with no trouble.

[juj]

Reading the disassembly at https://godbolt.org/z/rc3eoGaG9 , the generated code for __stack_avail, _assert, _CHROUT and chrout_u16 all look good to me. I suspect this would be something to do with varargs handling.

[juj]

Super random, but adding __asm__("NOP":::"memory"); statement right after either call to chrout_u16 make the bug vanish. E.g.

    ...
    switch(*format)
    {
    case 'd':
      dst = va_arg(args, int);
      if (dst < 0) { _CHROUT('-'); dst = -dst; }
      chrout_u16(dst);
      __asm__("NOP":::"memory"); // added this
    break;
    case 'u':
      dst = va_arg(args, unsigned int);
      chrout_u16(dst);
    break;
    }
    ...

does not have the issue. (Again really odd since the case 'd' is not even reached).

Alternatively, adding that __asm__("NOP":::"memory"); right after the second chrout_u16(dst); in case 'u': also removes the bug.

But adding __asm__("NOP":::"memory"); at the end inside of chrout_u16(dst); function implementation itself does not fix the issue.

Not sure if all that is a red herring or what. Diffing what the compiler codegens differently when that NOP is added, I see this:

On the left is code inside the switch-case in the bad scenario when that dummy NOP is not present. On the right is the code with the NOP added.

It is kind of hard to make heads or tails out of it, but one thing I do notice is that in the bad case on the left, the compiler has somehow merged case 'd': and case 'u': together, since on the left it contains only one call to chrout_u16(dst);. On the right however, with that NOP, the second call to chrout_u16(dst); is introduced.

[juj]

Fantastic digging. That sounds like it wasn't related to the varargs part then after all.