similar to: [LLVMdev] Named register variables GNU-style

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 =

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;

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, 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 28 March 2014 02:06, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Correct. The proposed solution would work for all non allocatable > registers. We should probably still err if someone tries to use an > allocatable one. AFAIK, GCC reserves the allocatable registers. If we're going to do this we'd have to be as close as possible to the current behaviour to

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,

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

On 27 March 2014 19:35, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > Is there any sane reason to actually implement it? Bare metal code is never sane, but that's not an excuse not to write it. C is a very complete language, especially modern variations like C11, but there's still a lot that can't be done in C and for good reasons. Kernel code and optimal

On 28 March 2014 10:17, Chandler Carruth <chandlerc at google.com> wrote: > This has been the long standing historical objection to the feature. It is a > *really* invasive change to the register allocator to plumb this kind of > register reservation through it. Do you mean only the reserved part or the general named register idea? About reserving registers, we already have the

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:

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

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

Richard Smith <richard at metafoo.co.uk> writes: > On Fri, Mar 28, 2014 at 4:50 AM, Renato Golin <renato.golin at linaro.org>wrote: >> 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

On 29 March 2014 10:37, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > I'd like to separate this into two different functionalities: We will. But in reverse order. > (1) Reserve registers, so that normal allocation won't use them. > This can be done on a global or function level. This is the most controversial part of the proposal and is the least important to

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

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

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 28 March 2014 16:12, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > I mean how do you make sure that the "write" builtin does not look like dead > code, and at the same time it's not treated as something that "changes > everything". On the IR level, I expect a call to an intrinsic to never be pruned. But I also need more guarantees regarding

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