llvm dev - Feb 2016 - [PPC] Linker fails on -fstack-protector

On Mon, Feb 22, 2016 at 3:32 PM Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Mon, Jan 25, 2016 at 07:57:43PM +0000, Tim Shen via llvm-dev wrote:
> > A cleaner solution could be adding an IR intrinsic
llvm.get_tcb_address()
> > and hard code the offset of stack_guard member, since they aren't
> supposed
> > to change.
>
> It would also be inefficient on architectures that can directly access
> TLS variables. I.e. on x86, it is effectively a statically allocated TLS
> variable with fixed offset. That can be accessed by a single load --
> whereas introducing get_tcb_address first would require a second load.

Guess I used the wrong intrinsic name - it should be
llvm.global_tls_address(), and it should be directly lowered to
ISD::GlobalTLSAddress, which is currently used by both x86 and ppc, and
ultimately it's referencing fs register on x86_64 and r13 on ppc64le.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160223/6fb9314a/attachment.html>

On Tue, Feb 23, 2016 at 12:26:54AM +0000, Tim Shen
wrote:
> On Mon, Feb 22, 2016 at 3:32 PM Joerg Sonnenberger via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> 
> > On Mon, Jan 25, 2016 at 07:57:43PM +0000, Tim Shen via llvm-dev wrote:
> > > A cleaner solution could be adding an IR intrinsic
llvm.get_tcb_address()
> > > and hard code the offset of stack_guard member, since they
aren't
> > supposed
> > > to change.
> >
> > It would also be inefficient on architectures that can directly access
> > TLS variables. I.e. on x86, it is effectively a statically allocated
TLS
> > variable with fixed offset. That can be accessed by a single load --
> > whereas introducing get_tcb_address first would require a second load.
> 
> 
> Guess I used the wrong intrinsic name - it should be
> llvm.global_tls_address(), and it should be directly lowered to
> ISD::GlobalTLSAddress, which is currently used by both x86 and ppc, and
> ultimately it's referencing fs register on x86_64 and r13 on ppc64le.
You can get the TCB address from %fs:0 or %gs:0 on x86. But that's
suboptimal for the purpose here as you need to do a second load with the
resulting pointer, when you could have gotten it from %fs:$magic_offset
or %gs:$magic_offset in first place.

Joerg

On Tue, Feb 23, 2016, 04:50 Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> You can get the TCB address from %fs:0 or %gs:0 on x86. But that's
> suboptimal for the purpose here as you need to do a second load with the
> resulting pointer, when you could have gotten it from %fs:$magic_offset
> or %gs:$magic_offset in first place.
>
Isn't LLVM already combining a register load with an offset (0) followed by
another offset-load? If it's currently not implemented, it seems quite
useful and generic, and we should just implmenet it?

If for some reason it can't be done, we can still pass the offset into the
intrinsic, as ISD::GlobalTLSAddress is designed.

ISD::GlobalTLSAddress is actually quite close to what we want - except for
a GlobalValue it requires. Maybe we can make that requirement optional?
E.g. if a nullptr is passed in as the GlobalValue, generate fs:offset,
rather than fs:@a+ offset.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160223/badf2f6a/attachment-0001.html>