[llvm-dev] llvm.read_register for %RIP on x86_64
Bruce Hoult via llvm-dev
llvm-dev at lists.llvm.org
Thu Feb 2 14:57:36 PST 2017
Efficient looking on a 386, sure, but I presume you're running AMD64 code
on a modern CPU :-)
I suggest you try:
On Fri, Feb 3, 2017 at 12:14 AM, Kostya Serebryany via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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"),
> It generates a pretty efficient-looking code:
> 42194c: 48 8d 0d 00 00 00 00 lea 0x0(%rip),%rcx # 421953
> 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. :(
> 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>
>>> 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.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev