llvm dev - Mar 2014 - [LLVMdev] Named register variables GNU-style

On Thu, Mar 27, 2014 at 9:30 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
> > That's my idea, yes. I'm not sure how Clang would transform
the named
> > registers into the intrinsic, but something along the lines of:
> >
> > i8* @SP = "SP";
> >
> > define void @step() nounwind {
> > entry:
> >   %0 = call i32 @llvm.read_register(i8* @SP)
> >   %1 = add i32 %0, i32 4
> >   call void @llvm.write_register(i8* @SP, %1)
> > }
> >
> > declare void @llvm.write_register(i8*, i32) nounwind readnone
> > declare i32 @llvm.read_register(i8*) nounwind readnone
>
> I would not produce any llvm global for it. So some insanity like
>
> register long a asm("rsp");
> long f(long x) {
>   long ret = a;
>   a = x;
>   return ret;
> }
>
> would compile to
>
> define i64 @f(i64 %x) {
>   %ret = call i64 @llvm.read_register("rsp");
>   call void @llvm.write_register("rsp", i64 %x)
>   ret %ret
> }
> declare void @llvm.write_register(i8*, i64)
> declare i64 @llvm.read_register(i8*)

I don't think that works. Per the GCC documentation, a global register
variable reserves the register entirely for use with that name in a
translation unit. We don't seem to want exactly that model, but the
approach you're suggesting doesn't seem to capture the semantics. For
instance:

register long a asm("r12");
void f(long n) {
  n *= 3;
  a += n;
}

... could do the wrong thing if the multiplication happens to use r12.
>> This is not exactly the semantics gcc uses since the register would
> >> still be allocatable, but should cover 99% of the uses, including
> >> reading the stack pointer in the kernel.
> >
> > http://gcc.gnu.org/onlinedocs/gcc/Global-Reg-Vars.html
> >
> > It seems that the semantics is to avoid PCS registers, or they will be
> > clobbered...
>
> Yes, it is really odd. It says "Global register variables reserve
> registers throughout the program.", which is obviously not the case
> since not all compile units might see it.
>
> >
> >> For example, is it legal to move the read of rsp out of  a
> >> loop?
> >
> > No. It should be a volatile read/write.
>
> Agreed. With the intrinsic the semantics are easy to represent.
>
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140327/23ba1b97/attachment.html>

On 27 March 2014 21:52, Richard Smith <richard at metafoo.co.uk>
wrote:
> I don't think that works. Per the GCC documentation, a global register
> variable reserves the register entirely for use with that name in a
> translation unit. We don't seem to want exactly that model, but the
approach
> you're suggesting doesn't seem to capture the semantics.
The IR in question has no mention that the register cannot be
reserved. In fact we do that already in the ARM back-end, reserving
the R9 for special purposes. We could very well reserve the register
in question to not be used. Some of us also mentioned that we should
reserve the register, and I think there's nothing stopping us from
reserving the registers on a compilation unit (module) level for
global named registers.

The problem here is that you can't reserve all registers. On ARM,
R0~R3, SP, LR and PC (and sometimes R9 or R11) cannot be fully
reserved, as they are part of the PCS/execution model, or are reserved
already. GCC docs state that "it's not safe" assuming those things
will by reserved, which is the same effect. The stack pointer can
still be safely used for reading, for example, as is the case of
unwinding.

cheers,
--renato

> I don't think that works. Per the GCC documentation, a global register
> variable reserves the register entirely for use with that name in a
> translation unit. We don't seem to want exactly that model, but the
approach
> you're suggesting doesn't seem to capture the semantics. For
instance:
>
> register long a asm("r12");
> void f(long n) {
>   n *= 3;
>   a += n;
> }
>
> ... could do the wrong thing if the multiplication happens to use r12.
Correct. The proposed solution would work for all non allocatable
registers. We should probably still err if someone tries to use an
allocatable one.

Cheers,
Rafael

On 28 March 2014 02:06, Rafael Espíndola <rafael.espindola at gmail.com>
wrote:
> Correct. The proposed solution would work for all non allocatable
> registers. We should probably still err if someone tries to use an
> allocatable one.
AFAIK, GCC reserves the allocatable registers. If we're going to do
this we'd have to be as close as possible to the current behaviour to
avoid surprises.

--renato