similar to: llvm.read_register for %RIP on x86_64

On 26 January 2017 at 00:08, Kostya Serebryany via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I want implement an instrumentation that gets the current PC. > On x86_64 I can do it using inline asm (something like "lea (%%rip),%0"), > but I wonder if there is some more LLVM-ish way to do it, e.g. an intrinsic? Hi Kostya, I'd also want something that GCC

On Thu, Jan 26, 2017 at 1:45 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 26 January 2017 at 00:08, Kostya Serebryany via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I want implement an instrumentation that gets the current PC. > > On x86_64 I can do it using inline asm (something like "lea (%%rip),%0"), > > but I wonder if there

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

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

On 27 March 2014 15:30, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > For global ones, it should also codegen every non inline asm to use an > llvm intrinsic (llvm.read_register/llvm.write_register for example). That's my idea, yes. I'm not sure how Clang would transform the named registers into the intrinsic, but something along the lines of: i8* @SP =

Hi, I'm trying to use the statepoint-example strategy to build a simple garbage collector. After using the PlaceSafepoints and RewriteStatepointsForGC passes, I can successfully generate a stack map in my binary and call into my runtime's gc poll. As far as I can tell, I need the stack pointer at the point of the poll to find the correct frame in the stack map. I'm having trouble

Sorry, what does "PC" mean here? ________________________________ From: Philip Reames <listmail at philipreames.com> Sent: Thursday, November 8, 2018 7:27 AM To: Jordan Rudd; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Passing stack pointer to statepoint-gc Jordon, First of all, StackMaps are keyed by PC, not by SP. Each entry corresponds to given location within the

On Sat, Mar 29, 2014 at 11:46:13AM +1030, Jeremy Lakeman wrote: > declare void @llvm.write_register.sp(i32 val) > declare i32 @llvm.read_register.sp() I'd prefer to use declare void @llvm.write_register(i32 regno, i32 val) declare i32 @llvm.read_register(i32 regno) where regno is the DWARF name or a special reservation e.g. for IP or SP. Joerg

Folks, So, I think we kind of agree that some named registers could be implemented, and that it should be an intrinsic that passes the name of the register down. This C code: register unsigned long current_stack_pointer asm("sp"); unsigned long get_stack_pointer_addr() { return current_stack_pointer; } void set_stack_pointer_addr(unsigned long addr) { current_stack_pointer = addr;

----- Original Message ----- > From: "Rafael Espíndola" <rafael.espindola at gmail.com> > To: "Renato Golin" <renato.golin at linaro.org> > Cc: "Clang Dev" <cfe-dev at cs.uiuc.edu>, "LLVM Dev" <llvmdev at cs.uiuc.edu> > Sent: Thursday, March 27, 2014 11:30:46 AM > Subject: Re: [cfe-dev] [LLVMdev] Named register

Hi everyone, We seem to have allowed our documented target-independent intrinsics to acquire a somewhat-haphazard naming system, and I think we should standardize on one convention. All of the intrinsics have 'llvm.' as a prefix, and some also have some additional prefix 'llvm.dbg.', 'llvm.eh.', 'llvm.experimental.', etc., but after that we lose consistency. When

On Sat, Mar 29, 2014 at 12:36:45PM +0000, Renato Golin wrote: > On 29 March 2014 12:27, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > > declare void @llvm.write_register(i32 regno, i32 val) > > declare i32 @llvm.read_register(i32 regno) > > > > where regno is the DWARF name or a special reservation e.g. for IP or > > SP. > > Do front-ends

On Mon, Feb 22, 2016 at 5:00 PM Eric Christopher <echristo at gmail.com> wrote: > Yeah, for most of the architectures listed there it's not particularly > useful as they support direct access to TLS variables (as Joerg says > later). That grep isn't representative of how the data is actually > accessed. If the current address space way of specifying isn't doable on

On 2018-05-11 02:28, Andrew Kelley via llvm-dev wrote: > In the Zig frontend, we know at compile-time the entire call graph. > This means we know stack size for all functions and therefore the > upper bound stack usage. > > [snip] > 1. Is there a way to accomplish this with existing LLVM API? You should use the @llvm.stacksave and @llvm.stackrestore intrinsic. It is only legal

On Thu, Mar 27, 2014 at 9:30 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > That's my idea, yes. I'm not sure how Clang would transform the named > > registers into the intrinsic, but something along the lines of: > > > > i8* @SP = "SP"; > > > > define void @step() nounwind { > > entry: > > %0 = call i32

On 29 March 2014 13:38, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > I disagree. It is the *easy* part to get many known users to work. This > includes a bunch of kernels, Lisp implementations etc. The rest can be > implemented on top by hand using inline asm, so this is the crucial > part. Let me re-phrase my opinion... >From all discussions on the LLVM list,

Folks, I just had a discussion about __builtin_stack_pointer in the GCC list, and there were a number of arguments against it, and it got me thinking I didn't have strong arguments against GNU's named register extension. Does anyone remember the arguments for not implementing that extension? My view is that making it an intrinsic (say @llvm.register(name)) would have the exact same

Rather than bending over backwards to keep all of this working, we should try to add the IR facilities needed to avoid these problems. This is the result of a discussion between myself Duncan and Eric (all of us probably relaying ideas from still other discussions) that I'm trying to write down here because none of us are going to be able to prioritize working on this soon. If anyone else

I don’t know yet, but I will let you know as soon as I can. On Nov 14, 2013, at 10:18 PM, Kostya Serebryany <kcc at google.com> wrote: > On Fri, Nov 15, 2013 at 10:16 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> No, not that I am aware of. > > So, if my commits did indeed trigger the failures it could be > something like binary size change that caused

On Feb 7, 2012, at 4:04 PM, Kostya Serebryany wrote: > On Tue, Feb 7, 2012 at 3:46 PM, John McCall <rjmccall at apple.com> wrote: > On Feb 7, 2012, at 2:07 PM, Kostya Serebryany wrote: > > Slightly formatted/commented patch. > > WDYT? > > This seems to work fine, except that reading a field from a const > AttrConst is not a constant expression in C++03, so the