On Mar 27, 2014, at 6:38 AM, Renato Golin wrote:
> On 27 March 2014 10:29, Andreas Schwab wrote:
>> Depends on what you need the value for.
>
> Mostly unwind code that uses both FP and SP, example:
But unwind code is inherently platform-dependent. Your objection to the inline
asm that refer
On 27 March 2014 15:06, wrote:
> But unwind code is inherently platform-dependent. Your objection to the
> inline asm that references SP by name is that it's platform dependent. The
> builtin would reduce the amount of platform dependent code by one line, i.e.,
> probably much less than one
On 03/27/14 04:20, Renato Golin wrote:
Hi Jakub,
Just to make it clear, I'm not an official representative of Clang, or
LLVM, nor I was involved in all discussions about implementing
extensions either. I do not have an agenda to promote LLVM changes.
I also don't speak for either clang nor the L
On 27 March 2014 11:33, Jakub Jelinek wrote:
> Sure, normally register keyword is just a hint, that e.g. GCC I think
> ignores whenever optimizing (for -O0 it means a variable doesn't have to
> be allocated on the stack), but when it is part of the GNU global/local
> register
> variable extension
On Thu, Mar 27, 2014 at 11:20:09AM +, Renato Golin wrote:
> On 27 March 2014 10:44, Jakub Jelinek wrote:
> > I don't see what is wrong with this, this isn't inline asm, it is
> > the local register var GNU extension,
>
> The argument I remember hearing of is the joint of:
> 1. The "register"
Hi Jakub,
Just to make it clear, I'm not an official representative of Clang, or
LLVM, nor I was involved in all discussions about implementing
extensions either. I do not have an agenda to promote LLVM changes.
> To me this sounds like clang proposing extensions because they aren't
> willing to
On Thu, Mar 27, 2014 at 03:44:39AM -0700, Andrew Pinski wrote:
> > (so you need to split by arch with ifdefs),
>
> Except it is already in the kernel anyways; not even by ifdefs but by
> different files so the reasoning adding a new builtin is not useful.
Not to mention that the kernel probably w
On 27 March 2014 10:47, Andrew Pinski wrote:
> Please don't add a close list to the CC of GCC lists it is annoying.
I didn't realise this list was closed, sorry.
--renato
tin is not useful.
Please don't add a close list to the CC of GCC lists it is annoying.
-- Forwarded message --
From:
Date: Thu, Mar 27, 2014 at 3:44 AM
Subject: Your message to LLVMLinux awaits moderator approval
To: pins...@gmail.com
Your mail to 'LLVMLinux' with
On Thu, Mar 27, 2014 at 3:25 AM, Renato Golin wrote:
> On 27 March 2014 10:12, Andreas Schwab wrote:
>> Can't you use __builtin_frame_address (0) instead?
>
> That would give me the frame pointer, not the stack pointer, and the
> user would have to calculate manually the offset to get the actual
On Thu, Mar 27, 2014 at 09:38:11AM +, Renato Golin wrote:
> There is a common pattern on bare-metal code to refer to the value of
> registers directly in a variable:
>
> register unsigned long current_stack_pointer asm("sp");
I don't see what is wrong with this, this isn't inline asm, it is
On 27 March 2014 10:29, Andreas Schwab wrote:
> Depends on what you need the value for.
Mostly unwind code that uses both FP and SP, example:
http://git.linuxfoundation.org/?p=llvmlinux/kernel.git;a=commit;h=a875939682dc43bf244bd39a356bca76ac190d77
http://git.linuxfoundation.org/?p=llvmlinux/ker
Renato Golin writes:
> On 27 March 2014 10:12, Andreas Schwab wrote:
>> Can't you use __builtin_frame_address (0) instead?
>
> That would give me the frame pointer, not the stack pointer, and the
> user would have to calculate manually the offset to get the actual
> stack pointer, which would be
On 27 March 2014 10:12, Andreas Schwab wrote:
> Can't you use __builtin_frame_address (0) instead?
That would give me the frame pointer, not the stack pointer, and the
user would have to calculate manually the offset to get the actual
stack pointer, which would be target-specific, possibly making
Renato Golin writes:
> Basically, introducing the builtin: __builtin_stack_pointer() which
> will return the stack pointer register's value. There's no guarantee
> that the register will contain the information you want (for example,
> if the surrounding code uses it) and is only meant to replace
15 matches
Mail list logo
