[LLVMdev] Named register variables GNU-style, deux

[Renato Golin]

On 19 April 2014 19:41, Austin Seipp <aseipp at pobox.com> wrote:
> Recently on this list (as of last month), Renato Golin of Linaro
> posted a thread entitled "Named register variables, GNU-style"[1].

Hi Austin,

FYI, this is the (now outdated) first proposal on the non-allocatable registers:

http://reviews.llvm.org/D3261

I read your email to the end and I understand why this is not good enough.


> Again, the performance difference between these two snippets cannot be
> understated. And pthread_{get,set}specific do even worse because
> they're not inlined at all (remember, we're talking 25-30% loss for
> all programs.)

It's for problems like these that the named GPRs feature exist (not
the stack register trick), but there are two issues that need to be
solved, and I'm solving one at a time.


> First, obviously, is that this need precludes Renato's proposal that
> only non-allocatable registers must be available.[3] We absolutely
> have to have GPRs available, and nothing else makes sense for our use
> case.

I believe we really should have GPRs in the named register scheme in
the future, but there are other problems that need to be dealt with
first, as Chandler exposed.

This is not flogging a dead horse and a feature that I believe is
important, not because it's heavily used by many people, but because
it's sparsely used by critical parts of very low level software that
needs the extra edge to give *all* relying dependent software a big
performance boost. People writing high-level software should not use
(like inline asm, etc) or will suffer the consequences.

We need to do the following steps, in order:

1. create the representation in IR (the intrinsics, metadata, etc),
and to lower it on some back-ends without any special reservation. (my
current work)

2. make it possible to add GPRs to the reserved list of the allocator
on a module scope (from those metadata nodes) and create some tests
with edge cases (especially ABI-related registers) to make sure the
code generation won't go crazy or pervert the ABI, creating
error/warning messages for the cases where it does.

3. move the code in with a flag to enable it, and let it run for a few
months/releases.

4. when the dust settles, make it default on.

I don't think enabling this feature by default will have any impact in
current code, since if you don't use it, there's no difference. But
the worry is that code that used it (and will be now compiled with
Clang/LLVM) will perform badly/wrong. Since this is an experimental
feature, on very specific code, I think the problems we'll see will be
manageable.

I'll get to step 1 next week, and we should start thinking about the
GPRs issue right afterwards. Since that's not particularly important
for me right now (the kernel doesn't need it), I may slow down a bit,
so your help (and those that need it) will be highly appreciated.

I may be wrong, but from what I've seen of the reservation mechanism,
it shouldn't be too hard to do it dynamically on a module-level. But I
only want to start thinking about it when I finish step 1.

Makes sense?

cheers,
--renato