search for: __builtin_stack_pointer

...}) >>> >>> /jakob >> That seems to work! Though I'm still testing it in all our situations >> for LLVMLinux. It looks like I can get this to work with LLVM 3.3 and >> the LLVMLinux kernel patches. Thanks! >> >> However, I'd still like to see __builtin_stack_pointer() added since it >> is simple, obvious, and mirrors other builtins like >> __builtin_frame_address(). > Ping on this? Sorry. Been away from my desk for 2 weeks (Linux Con, Embedded Linux Con, and a week teaching). Just catching up this week. The suggested work around DOES work for m...

...>> esp; \ >> }) >> >> /jakob > That seems to work! Though I'm still testing it in all our situations > for LLVMLinux. It looks like I can get this to work with LLVM 3.3 and > the LLVMLinux kernel patches. Thanks! > > However, I'd still like to see __builtin_stack_pointer() added since it > is simple, obvious, and mirrors other builtins like > __builtin_frame_address(). Ping on this? It seems like a legitimate builtin to have in clang, if only for compatibility and the nicer IR representation. Alp. > > Behan > -- http://www.nuanti.com the browse...

...("" : "=r"(esp)); \ > esp; \ > }) > > /jakob That seems to work! Though I'm still testing it in all our situations for LLVMLinux. It looks like I can get this to work with LLVM 3.3 and the LLVMLinux kernel patches. Thanks! However, I'd still like to see __builtin_stack_pointer() added since it is simple, obvious, and mirrors other builtins like __builtin_frame_address(). Behan -- Behan Webster behanw at converseincode.com

...eed to copy the stack pointer to another register, but first that register needs to be saved to the stack and then restored after the stackpointer has been used; inefficient. Another way would be to introduce a new builtin in parallel to others like __builtin_return_address(). Essentially adding a __builtin_stack_pointer() which does what the above code does. The idea would be to get something like this added to both clang and gcc in order to make this work across compilers, and across arches. It ends up being a trivial patch for clang (see below). We're still looking for someone to help us on the gcc side. T...

...ually no #ifdef is required with Jakob's suggestion (works the same >> in both clang and gcc). >> > > It may works for both GCC and clang, it does not means it will works > with every arch linux supports (ARM, PPC, AArch, …) True enough. Which is indeed another argument for __builtin_stack_pointer(). That point is precisely one of the reasons that we're pushing for this addition. Behan -- Behan Webster behanw at converseincode.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131105/33db5464...

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

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

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

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

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

...of named registers, and gives us the same level of guarantees, so, in the end, there isn't much *technical* difference in doing one and the other, with the added benefit that named registers are already widely used and you won't need to add ifdefs for new compilers. > We have the > __builtin_stack_pointer now, which is somewhat questionable[1], however this > should not serve a precedent to implement further "extensions" like this. No we don't. Not yet. ;) I was about to commit when I thought I should get a point of view from all sides, including (and especially) GCC. The first i...

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,

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

...ules, the lack of inline asm knowledge in the back-end (fixed by MC and IAS), and the lack of register reservation mechanisms (which we have today). So, while I appreciate there is vast historical reasons to not support it, otherwise Mark and Behan would not have gone that far convincing us of the __builtin_stack_pointer in the first place, I believe that, not only the harder technical problems have being fixed by now, but the arguments towards builtins are less technically valid than the ones supporting named registers. > Worse, the semantics for it being > inherently translation-unit based become deeply...