Jean-Daniel Dupas
2013-Nov-05 19:30 UTC
[LLVMdev] A new builtin: __builtin_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 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 current_stack_pointer ({ \ >>>> unsigned long esp; \ >>>> asm("mov %%esp, %0" : "=r"(esp)); \ >>>> esp; \ >>>> }) >>>> >>>> This works for both gcc and clang, but often adds in 3 extra >>>> instructions since you need 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. >>> #define current_stack_pointer ({ \ >>> register unsigned long esp asm("esp"); \ >>> asm("" : "=r"(esp)); \ >>> esp; \ >>> }) >> And #ifdef it for each arch? Builtin would be much more handy. > Actually 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, …)> However the builtin is indeed nicer, easier to read and much more in > keeping with the other builtins... > > Behan> - Jean-Daniel-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131105/72e80344/attachment.html>
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 Oct 10, 2013, at 12:32 PM, Behan Webster >>>> <behanw at converseincode.com <mailto: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 asm("esp"); >>>>> >>>>> clang doesn't allow this kind of thing which required a patch >>>>> which less >>>>> efficient: >>>>> >>>>> #define current_stack_pointer ({ \ >>>>> unsigned long esp; \ >>>>> asm("mov %%esp, %0" : "=r"(esp)); \ >>>>> esp; \ >>>>> }) >>>>> >>>>> This works for both gcc and clang, but often adds in 3 extra >>>>> instructions since you need 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. >>>> #define current_stack_pointer ({ \ >>>> register unsigned long esp asm("esp"); \ >>>> asm("" : "=r"(esp)); \ >>>> esp; \ >>>> }) >>> And #ifdef it for each arch? Builtin would be much more handy. >> Actually 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/attachment.html>
Hi Behan, Only saw this thread now. I think having the built-in makes sense, but you sent the description and patch to the LLVM list, not the Clang list. ;) I'd copy the cfe-dev, but I think now the thread is more complex than cross-posting would allow. So, maybe it'd be better if you posted there again, your original email, the patch and some of the comments on this thread. cheers, --renato On 5 November 2013 16:15, Behan Webster <behanw at converseincode.com> wrote:> On 11/05/13 11:30, Jean-Daniel Dupas wrote: > > > 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 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 current_stack_pointer ({ \ > unsigned long esp; \ > asm("mov %%esp, %0" : "=r"(esp)); \ > esp; \ > }) > > This works for both gcc and clang, but often adds in 3 extra > instructions since you need 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. > > #define current_stack_pointer ({ \ > register unsigned long esp asm("esp"); \ > asm("" : "=r"(esp)); \ > esp; \ > }) > > And #ifdef it for each arch? Builtin would be much more handy. > > Actually 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 Websterbehanw at converseincode.com > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131106/4f6164ab/attachment.html>