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 implement existing extensions, not a good reason to change.
Whatever I say or propose is only my limited view of the world as of a
few years ago (when I started working with LLVM) and I'm mainly
discussing this here exactly because I don't want to implement
extensions just for the sake of it, and I want opinions from all
angles before taking any *technical* decision. The arguments you guys
are giving to me are solid and will be taken back to the LLVM list to
discuss this further (after I do some research on past discussions).
Please, don't take my emails as "Clang pushing GCC to do things", as
they're *clearly* not. If anything, they're only a display or my own
ignorance.
AFAIK, the whole idea of __builtin_stack_pointer was to mimic the
already existing __builtin_frame_address, but the usage and examples
you and Andrew gave me (separate files, not meaningful in all targets)
show why it hasn't been done in GCC.
I honestly took it as a simple oversight of kernel engineers
implementing something that could be done better in a way GCC already
understood (as it happens a lot, example is the inline asm + Macro
issue we raised earlier). It seems this time, it was not.
On 27 March 2014 10:44, Jakub Jelinek <ja...@redhat.com> 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" specifier is not guaranteed to keep variables'
values in registers (C99, 6.7.1p4)
2. Representing register names are not possible in LLVM IR at the moment
I understand that these reasons are not stronger than the case both
you and Andrew made.
In theory, if we can lower SP as a register value, we should be able
to lower any register. So we should be able to create an intrinsic
that maps that specific construct into a name, for example:
%reg = @llvm.register("sp")
And lower the same way Marc's code lowers the stack pointer. I'll
follow up on the LLVM list.
> which is far more general then this
> proposal. Using stack pointer is inherently target specific anyway, some
> targets (e.g. sparc64) apply e.g. a bias to the stack pointer register,
> it is unclear what this builtin would do in that case.
This is true. Joined with the fact that Andrew mentioned, that the
code is split in files anyway, our proposal loses a lot of weight.
Thanks both for your comments!
cheers,
--renato
