search for: read_regist

...n 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 understands, as this code could end > up there, too. > > The read_register intrinsic can be lowered by Clang from a number of > different builtins, so we could easily "support" some already-existing > GCC builtin for reading the PC, if you need to get it from C code. > > Right now, the read_register is locked at the stack pointer as a > design d...

Hi, 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? I can only find r208104 which introduces llvm.read_register: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20140505/215840.html The LangRef says: > Warning: So far it only works with the stack pointer on selected architectures (ARM, AArch64, > PowerPC and x86_64). Significant amount of work is needed to support other registers and even &...

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 de...

...t 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 understands, as this code could end up there, too. The read_register intrinsic can be lowered by Clang from a number of different builtins, so we could easily "support" some already-existing GCC builtin for reading the PC, if you need to get it from C code. Right now, the read_register is locked at the stack pointer as a design decision. We do not know,...

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 = "SP"; define void @step() nounwind { entry: %0 = call i32 @llvm.read_register(i8* @SP) %1 = ad...

...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 P...

...P register to RDI before calling into the runtime, so that the runtime gc polling function can read it as a parameter. I was trying to do the same thing except in llvm, so from my gc.safepoint_poll definition, I tried adding these lines: declare void @runtime_safepoint_poll(i64) declare i64 @llvm.read_register.i64(metadata) #1 !0 = !{!"rsp\00"} ; Read the stack pointer and pass it to our polling function (assumes x64) define void @gc.safepoint_poll() { %stackpointer = call i64 @llvm.read_register.i64(metadata !0) call void @runtime_safepoint_poll(i64 %stackpointer) ret void } attribut...

...ack_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; } Would become something like: define i32 @get_stack_pointer_addr() nounwind { entry: %0 = call i32 @llvm.read_register("sp") ret i32 %0 } define void @set_stack_pointer_addr(i32 %addr) nounwind { entry: call void @llvm.write_register("sp", %addr) ret void } Note particularly: - There are no globals defined. Since you can't take the address of that variable, you can only read and w...

...P register to RDI before calling into the runtime, so that the runtime gc polling function can read it as a parameter. I was trying to do the same thing except in llvm, so from my gc.safepoint_poll definition, I tried adding these lines: declare void @runtime_safepoint_poll(i64) declare i64 @llvm.read_register.i64(metadata) #1 !0 = !{!"rsp\00"} ; Read the stack pointer and pass it to our polling function (assumes x64) define void @gc.safepoint_poll() { %stackpointer = call i64 @llvm.read_register.i64(metadata !0) call void @runtime_safepoint_poll(i64 %stackpointer) ret void } attribut...

...;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 @llvm.read_register(i8* @SP) > > %1 = add i32 %0, i32 4 > > call void @llvm.write_register(i8* @SP, %1) > > } > > > > declare void @llvm.write_register(i8*, i32) nounwind readnone > > declare i32 @llvm.read_register(i8*) nounwind readnone > > I would not produce any llv...

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

...is just a single word (or acronym) everything is fine, but the way we join multiple words (or acronyms) falls into three categories: 1. No separator (e.g. @llvm.readcyclecounter) 2. Using '.' as a separator (e.g. @llvm.sadd.with.overflow) 3. Using '_' as a separator (e.g. @llvm.read_register) I propose that we standardize on (2) -- words with dots -- as it seems to have a plurality of more-recent intrinsics (and I think it is easy to read, as is (3)). Thoughts? Although this is somewhat subjective, here's our current set of intrinsics with multiple words (or acronyms) by these...

...; 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 @llvm.read_register(i8* @SP) > > %1 = add i32 %0, i32 4 > > call void @llvm.write_register(i8* @SP, %1) > > } > > > > declare void @llvm.write_register(i8*, i32) nounwind readnone > > declare i32 @llvm.read_register(i8*) nounwind readnone > > I would not produce any llvm...

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,

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 have that info with them? AFAICR, front-ends only emit > metadata related to variables and they let the lowering process to > deal with location. I wan...

...pecific AArch64ISD::THREAD_POINTER and Intrinsic::aarch64_thread_pointer. To make the fix least surprising, I can either do: 1) Create PPCISD::THREAD_POINTER and Intrinsic::ppc_thread_pointer and do similar things aarch64 does; or 2) Don't create PPCISD::THREAD_POINTER, but directly calls llvm.read_register intrinsic in ppc's getStackCookieLocation(). This is the way that requires least change; or 3) Create a generic ISD::GET_GLOBAL_TLS_ADDRESS and intrinsic llvm.get_global_tls_address(), and lower them to target specific ISD. No target specific intrinsic is needed. I was wrong about ISD::Global...

...e > 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 to pass a value returned by stacksave to stackrestore. If you need more control, consider @llvm.read_register and @llvm.write_register intrinsics, which allow arbitrary manipulation of the stack pointer (but, I think, will inhibit optimizations more). -- whitequark

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

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. Recursive calls can have a runtime-decided stack usage, and therefore I am adding a frontend feature that will heap-allocate memory to use for some function calls. The idea is that recursion adds cycles to the call graph, and we know at

...; >> [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 to pass a value returned by stacksave to stackrestore. > If you need more control, consider @llvm.read_register and > @llvm.write_register intrinsics, which allow arbitrary manipulation > of the stack pointer (but, I think, will inhibit optimizations more). > Thanks,I'll try this: %0 = @llvm.stacksave @llvm.write_register ; set the new stack pointer call ; hopefully this uses the new stack p...