[SPARC64] Preserve registers used during optimization transforms

[koachan]

GCC might decide to put the result of the operation in another register, so remove hardcodings of %o0 as the destination register (rd field) during the transform of those relocations.

[koachan]

To elaborate more, I'm observing that GCC could emit something like this:

  28:   21 00 00 00     sethi  %hi(0), %l0
                        28: R_SPARC_TLS_LDM_HI22        CurrentThreadTaskGroups
  30:   a0 04 20 00     add  %l0, 0, %l0
                        30: R_SPARC_TLS_LDM_LO10        CurrentThreadTaskGroups
  38:   23 00 00 00     sethi  %hi(0), %l1
                        38: R_SPARC_TLS_LDO_HIX22       CurrentThreadTaskGroups
  48:   a0 05 c0 10     add  %l7, %l0, %l0
                        48: R_SPARC_TLS_LDM_ADD         CurrentThreadTaskGroups
  4c:   a2 1c 60 00     xor  %l1, 0, %l1
                        4c: R_SPARC_TLS_LDO_LOX10       CurrentThreadTaskGroups
 214:   40 00 00 00     call  __tls_get_addr
                        214: R_SPARC_TLS_LDM_CALL       CurrentThreadTaskGroups
 218:   90 10 00 10     mov  %l0, %o0                   ! Set arguments to the call; note how this isn't marked with any relocations.
 21c:   a6 02 00 11     add  %o0, %l1, %l3
                        21c: R_SPARC_TLS_LDO_ADD        CurrentThreadTaskGroups

With the call instruction intact, this is not a problem since __tls_get_addr will take its argument from %o0 and put its return value in %o0 too.
However, with LD->LE optimization pass, the call instruction becomes a nop, which causes the mov to clobber %o0 with an indeterminate value, which causes %l3 to contain a wrong value too - this causes segfaults when the program later tries to access memory pointed to by %l3.

Unfortunately I still don't know how to intentionally trigger this lowering.

[koachan]

Just noticed something. GCC might insert uses of %o0 in between R_SPARC_TLS_LDM_ADD and the corresponding R_SPARC_TLS_LDM_CALL.
I think it's better to change approach and let the optimization of R_SPARC_TLS_LDM_ADD (and similar ones for R_SPARC_TLS_GD_ADD) respect the original rd value.

[rui314]

Is this ready to review? I think this change looks at least harmless.

[koachan]

Is this ready to review? I think this change looks at least harmless.

Yes, but one question: I've made another commit to remove hardcoded register usage, should I submit it as part of this PR or should I make another PR for it?

[koachan]

Okay I think it should be ready for review now.

[rui314]

Thanks. Regarding the code review process, I’m not too concerned about it because this is after all just a small project. I’ll commit follow-up patches if necessary, so no worries.