[llvmlinux] [PATCH 2/2] [DO-NOT-UPSTREAM][mips] Remove all instances of explicit register variables from the mips arch.

Daniel Sanders Daniel.Sanders at imgtec.com
Fri Dec 19 20:07:06 UTC 2014

> -----Original Message-----
> From: llvmlinux-bounces at lists.linuxfoundation.org [mailto:llvmlinux-
> bounces at lists.linuxfoundation.org] On Behalf Of Behan Webster
> Sent: 19 December 2014 18:08
> To: llvmlinux at lists.linuxfoundation.org
> Subject: Re: [llvmlinux] [PATCH 2/2] [DO-NOT-UPSTREAM][mips] Remove all
> instances of explicit register variables from the mips arch.
> On 12/19/14 06:07, Daniel Sanders wrote:
> >
> > Clang accepts the syntax but does not honour them. I've asked a
> > colleague to
> >
> > look into supporting explicit register variables in clang. For now,
> > remove the
> >
> > uses of this feature and accept the unnecessary moves.
> >
> We've been calling this "named registers". This is something which is
> used to access the value of the stack pointer in the ARM and AARCH64 ports.
> clang is supposed to honour these sorts of local allocations, but only
> if used in immediately proceeding ASM code (which appears to be the case
> here...). The problem is that the architecture of llvm doesn't really
> allow for register allocation to be reserved in general.

A colleague has been told the same thing on llvmdev. There's actually one case in the patch where it's not immediately used by inline asm code. It's the one in thread_info.h where it's trying to return $28. It's possible that it's the only one that's a genuine problem. I'll try reverting the others and see if it still boots.

Interestingly, there's a test in clang (test/CodeGen/2004-03-16-AsmRegisterCrash.c) that uses the same kind of code as the thread_info.h example. It doesn't check the output and when I looked at the output it didn't contain either register mentioned in the test. I've only tried the x86_64 case in gcc but it does appear to honour it there.

> Otherwise naming a register globally in clang does work, as long as its
> the stack pointer. ;)
> Renato Golan did the work to allow the preceding stack pointer
> allocation so we could get things like percpu variables and access to
> the task struct to work on ARM/AARCH64 kernels.

Assuming the thread_info.h one is the only real problem, I might be able to adapt that to support $28 too.

> This appears like it will be a difficult situation to resolve
> considering named registers seem to be used a lot in the MIPS kernel.
> Behan

Hopefully the information you've just given me will have made this a much easier problem :-). At the moment, I'm thinking that GCC promises a little more than it documents and that reads of uninitialized variables that are also named registers are also guaranteed to be lowered to reads of the specified register

> --
> Behan Webster
> behanw at converseincode.com
> _______________________________________________
> LLVMLinux mailing list
> LLVMLinux at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux

More information about the LLVMLinux mailing list