[LLVMdev] A new builtin: __builtin_stack_pointer()

Jean-Daniel Dupas devlists at shadowlab.org
Tue Nov 5 11:30:00 PST 2013


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>


More information about the llvm-dev mailing list