This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH/RFA] SH TLS support

Joern Rennecke wrote:
> Moreover, do you actually need the value in r0 for anything but calculating
> the jsr destination?  SH2 and later have the bsr instruction, so if we can
> just add the appropriate negative offset to the value at 1f, we get a much
> shorter sequence:
>         mov.l L2,r1
>         mov.l L1,r4
>         bsr @r1
>         add r12,r4
> L0:
> ....
> (in constant pool)
> L1:     .long   %a1@TLSGD
> L2:     .long   __tls_get_addr@PLT+(L2-L0)
> This should actually be a define_insn_and_split, with the splitting
> happening after reload (but before sched2 & machine_dependent_reorg),
> to each of the load separately.  The bsr, the add and the label shown
> as L0 here best stay together as one nominal instruction, so that we
> don't get any problems with instruction movement & duplication.
> The label can be implicit in an unspec value we use for the
> __tls_get_addr@PLT+(L2-L0) expression, and machine_dependent_reorg
> will have to make it explicit when it creates the constant pool entry,
> or - simpler, but more fragile, but that should really not be disturbed
> after machine_dependent_reorg - represent that label by a reference to the
> bsr/add/label instruction.

Hmm, I haven't thought the duplication issue through well enough before
reviewing your patch for that problem with the PIC code.  As soon as we
separate the load the call site, we need to represent the interdependency,
and we want to do this before sched2, which is before bb-reorder, so we
will be affected.

OTOH it appears what you want to do is basically just an add of a value to
r12 and a function call.  Note that splitters may produce patterns that
are in turn split, so you can have a define_insn_and_split for a TLS
reference that in its (post-reload) splitter part calls a function like
gen_call_call_pcrel, which will generate a pattern that will be immediately
split afterwards, so we can make use of the existing infrastructure for
PIC calls.
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]