[LLVMdev] A new builtin: __builtin_stack_pointer()

[Behan Webster]

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>