similar to: [LLVMdev] Named Register Implementation

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 =

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

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

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

On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: > One of the issues the LLVMLinux project is having is with the use of > named registers in the Linux kernel code. The kernel uses something like > this in order to assign a C variable name to a register (one for each > kernel arch). > > register unsigned long current_stack_pointer

11.10.2013, 01:39, "Jakob Stoklund Olesen" <stoklund at 2pi.dk>: > On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: > >>  One of the issues the LLVMLinux project is having is with the use of >>  named registers in the Linux kernel code. The kernel uses something like >>  this in order to assign a C variable name to a

On 10/10/13 22:01, Jakob Stoklund Olesen wrote: > On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: > >> One of the issues the LLVMLinux project is having is with the use of >> named registers in the Linux kernel code. The kernel uses something like >> this in order to assign a C variable name to a register (one for each >> kernel

Le 5 nov. 2013 à 19:00, Behan Webster <behanw at converseincode.com> a écrit : > On 11/05/13 09:26, Konstantin Tokarev wrote: >> >> 11.10.2013, 01:39, "Jakob Stoklund Olesen" <stoklund at 2pi.dk>: >>> On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: >>> >>>> One of the issues the LLVMLinux

One of the issues the LLVMLinux project is having is with the use of named registers in the Linux kernel code. The kernel uses something like this in order to assign a C variable name to a register (one for each kernel arch). register unsigned long current_stack_pointer asm("esp"); clang doesn't allow this kind of thing which required a patch which less efficient: #define

On 11/05/13 09:26, Konstantin Tokarev wrote: > > 11.10.2013, 01:39, "Jakob Stoklund Olesen" <stoklund at 2pi.dk>: >> On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: >> >>> One of the issues the LLVMLinux project is having is with the use of >>> named registers in the Linux kernel code. The kernel uses

On 20/10/2013 16:22, Behan Webster wrote: > On 10/10/13 22:01, Jakob Stoklund Olesen wrote: >> On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: >> >>> One of the issues the LLVMLinux project is having is with the use of >>> named registers in the Linux kernel code. The kernel uses something like >>> this in order to

On 11/05/13 11:30, Jean-Daniel Dupas wrote: > > Le 5 nov. 2013 à 19:00, Behan Webster <behanw at converseincode.com > <mailto:behanw at converseincode.com>> a écrit : > >> On 11/05/13 09:26, Konstantin Tokarev wrote: >>> >>> 11.10.2013, 01:39, "Jakob Stoklund Olesen" <stoklund at 2pi.dk >>> <mailto:stoklund at 2pi.dk>>:

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

----- 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 Thu, May 10, 2018 at 10:35 PM, whitequark <whitequark at whitequark.org> wrote: > 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

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