[Bug target/84010] [sparc64] Problematic TLS code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010 --- Comment #7 from James Clarke --- Eric, does the patch look fine to you? Do you want me to submit it to the mailing list, or is here ok?
[Bug target/84010] [sparc64] Problematic TLS code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010 --- Comment #6 from Richard Henderson --- For better rematerialization, I wonder if it wouldn't be better to represent this as (set (reg:P tmp) (const:P (unspec [(symbol_ref "xxx")] UNSPEC_TLSIE))) prior to reload, and split to sethi+add+ld only after reload. That makes the rhs CONSTANT_P, which gets us into the right sort of paths in lra and reload. It also means we'll never spill just part of the expression.
[Bug target/84010] [sparc64] Problematic TLS code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010 --- Comment #5 from James Clarke --- My patch seems to work for this case: sethi %tie_hi22(tcg_ctx), %g2 ... add %g2, %tie_lo10(tcg_ctx), %g1 ldx [%l7 + %g1], %g1, %tie_ldx(tcg_ctx) stx %g2, [%fp+1783] ! note this is %g2, i.e. just the hi22... callgen_new_label, 0 ldx[%g7+%g1], %i5 ... ldx [%fp+1783], %g1 ! reload the hi22 add %g1, %tie_lo10(tcg_ctx), %i5 ldx [%l7 + %i5], %i5, %tie_ldx(tcg_ctx) ldx [%g7+%i5], %g1 The code gen is something else; I don't understand why it spills the result of the hi22 and re-adds the lo10 (which takes the worst aspects of rematerialisation and spilling), but that's a whole other story.
[Bug target/84010] [sparc64] Problematic TLS code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-24 CC||ebotcazou at gcc dot gnu.org Summary|[sparc64] Bad TLS code |[sparc64] Problematic TLS |generation |code generation Ever confirmed|0 |1 --- Comment #4 from Eric Botcazou --- Ouch.
