llvm dev - Feb 2017 - llvm.read_register for %RIP on x86_64

On Tue, Jan 31, 2017 at 3:11 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 31 Jan 2017 8:58 p.m., "Kostya Serebryany" <kcc at
google.com> wrote:
>
> hmm. I am not sure I understood you. The last two paragraphs seem to
> contradict each other.
> So, you recommend to extend read_register to read the PC, or
> "read_register is locked at the stack pointer as a design
decision"?
>
>
> Both. :-)
>
> There was a design decision to only support SP because we had no clear
> case for anything other than the stack pointer.
>
> If you have one for the PC, it would be a much better technical decision
> to reuse the machinery that already exists, is documented and tested, than
> come up with an independent implementation.
>
> The discussion whether to support it in clang or not is orthogonal. But
> once decided that we should support reading the PC, then read_register is
> the obvious place.
>
> If the clang developers refuse the idea, then inline assembly is the only
> option that would work across compilers.
>
> Makes sense?
>
Yep, will give it a try.

>
> Cheers,
> Renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170131/e5bf7a07/attachment.html>

FTR:
I've made a simple experiment with inline asm, it's as simple as
InlineAsm::get(FunctionType::get(IntptrTy, false),
                             StringRef("lea (%rip),$0"),
StringRef("=r"),
                             /*hasSideEffects=*/false);

It generates a pretty efficient-looking code:
  42194c: 48 8d 0d 00 00 00 00 lea    0x0(%rip),%rcx        # 421953
<_Z3fooPi+0x13>
  421953: 48 89 0c c5 60 3a 08 mov    %rcx,0x1083a60(,%rax,8)
(first instruction gets the PC, the other stores it somewhere)

However, this introduces a significant slowdown in my case, over 20%
(I need to execute this roughly for 50% of basic blocks)

So, I'll be looking for some other solutions that don't require reading
the
PC this often. :(

--kcc


On Tue, Jan 31, 2017 at 3:13 PM, Kostya Serebryany <kcc at google.com>
wrote:
>
>
> On Tue, Jan 31, 2017 at 3:11 PM, Renato Golin <renato.golin at
linaro.org>
> wrote:
>
>> On 31 Jan 2017 8:58 p.m., "Kostya Serebryany" <kcc at
google.com> wrote:
>>
>> hmm. I am not sure I understood you. The last two paragraphs seem to
>> contradict each other.
>> So, you recommend to extend read_register to read the PC, or
>> "read_register is locked at the stack pointer as a design
decision"?
>>
>>
>> Both. :-)
>>
>> There was a design decision to only support SP because we had no clear
>> case for anything other than the stack pointer.
>>
>> If you have one for the PC, it would be a much better technical
decision
>> to reuse the machinery that already exists, is documented and tested,
than
>> come up with an independent implementation.
>>
>> The discussion whether to support it in clang or not is orthogonal. But
>> once decided that we should support reading the PC, then read_register
is
>> the obvious place.
>>
>> If the clang developers refuse the idea, then inline assembly is the
only
>> option that would work across compilers.
>>
>> Makes sense?
>>
>
> Yep, will give it a try.
>
>
>>
>> Cheers,
>> Renato
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170202/8c21975b/attachment.html>

Efficient looking on a 386, sure, but I presume you're running AMD64 code
on a modern CPU :-)

I suggest you try:

   call foobar
foobar:
   pop %rcx
   mov    %rcx,0x1083a60(,%rax,8)

On Fri, Feb 3, 2017 at 12:14 AM, Kostya Serebryany via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> FTR:
> I've made a simple experiment with inline asm, it's as simple as
> InlineAsm::get(FunctionType::get(IntptrTy, false),
>                              StringRef("lea (%rip),$0"),
StringRef("=r"),
>                              /*hasSideEffects=*/false);
>
> It generates a pretty efficient-looking code:
>   42194c: 48 8d 0d 00 00 00 00 lea    0x0(%rip),%rcx        # 421953
> <_Z3fooPi+0x13>
>   421953: 48 89 0c c5 60 3a 08 mov    %rcx,0x1083a60(,%rax,8)
> (first instruction gets the PC, the other stores it somewhere)
>
> However, this introduces a significant slowdown in my case, over 20%
> (I need to execute this roughly for 50% of basic blocks)
>
> So, I'll be looking for some other solutions that don't require
reading
> the PC this often. :(
>
> --kcc
>
>
> On Tue, Jan 31, 2017 at 3:13 PM, Kostya Serebryany <kcc at
google.com> wrote:
>
>>
>>
>> On Tue, Jan 31, 2017 at 3:11 PM, Renato Golin <renato.golin at
linaro.org>
>> wrote:
>>
>>> On 31 Jan 2017 8:58 p.m., "Kostya Serebryany" <kcc at
google.com> wrote:
>>>
>>> hmm. I am not sure I understood you. The last two paragraphs seem
to
>>> contradict each other.
>>> So, you recommend to extend read_register to read the PC, or
>>> "read_register is locked at the stack pointer as a design
decision"?
>>>
>>>
>>> Both. :-)
>>>
>>> There was a design decision to only support SP because we had no
clear
>>> case for anything other than the stack pointer.
>>>
>>> If you have one for the PC, it would be a much better technical
decision
>>> to reuse the machinery that already exists, is documented and
tested, than
>>> come up with an independent implementation.
>>>
>>> The discussion whether to support it in clang or not is orthogonal.
But
>>> once decided that we should support reading the PC, then
read_register is
>>> the obvious place.
>>>
>>> If the clang developers refuse the idea, then inline assembly is
the
>>> only option that would work across compilers.
>>>
>>> Makes sense?
>>>
>>
>> Yep, will give it a try.
>>
>>
>>>
>>> Cheers,
>>> Renato
>>>
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170203/200f0545/attachment.html>