search for: write_regist

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 = add i32 %0, i32 4 ca...

.... 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 pointer for stack arguments @ll...

...r_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 write directly to it, it should be safe to translate all reads and writes to intrinsics without any reference to a global variable....

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

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

...gt; 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 global for it. So some insanity like > > register long a asm("rsp");...

...gt; 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 global for it. So some insanity like > > register long a asm("rsp"); &...

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

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

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

...d.gather @llvm.masked.scatter @llvm.lifetime.start @llvm.lifetime.end @llvm.invariant.start @llvm.invariant.end @llvm.invariant.group.barrier @llvm.var.annotation @llvm.ptr.annotation @llvm.bitset.test Words with underscores (except for the initial namespace prefix): @llvm.read_register @llvm.write_register @llvm.clear_cache @llvm.instrprof_increment @llvm.instrprof_value_profile Thanks again, Hal -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory

...particular register (albeit encoding target-specific information like this isn't ideal). Another approach could be adding a parameter attribute (e.g. 'hidden' or 'outofband') that puts the parameter in some target-specific location. The 'llvm.read_register' and 'llvm.write_register' intrinsics would only be useful if they could guarantee the relevant register wasn't going to be overwritten in the meantime (and they'd also need to support more registers than currently). As for forwarding arguments, it seems like the combination of 'musttail' and varargs...

On 28 March 2014 11:16, Chandler Carruth <chandlerc at google.com> wrote: > Just the reserved part. Ok, in that case, I share you concerns. We could easily only implement the reserved ones (stack pointer being the case in hand). If there is any mad reason why allocatable ones should be used (I heard glibc uses R8 for some special things, haven't confirmed myself), we can discuss

On Thu, Apr 26, 2018 at 3:44 AM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > Most probably you need to properly specify the calling convention the > backend is using for calling the runtime functions. Thanks for the tip. Can you be more specific? Are you suggesting there is some config parameter I can set before running TargetMachineEmitToFile? Do you know what

Hi all, What do people think of doing away with the @llvm.convert.to.fp16 and @llvm.convert.from.fp16 intrinsics, in favour of using "half" and fpext/fptrunc? [1] It looks like those intrinsics originally date from before "half" actually existed in LLVM, and of course the backends have grown up assuming that's what Clang will produce, so we'd have to improve their