[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 21:08:53 UTC 2014

> -----Original Message-----
> From: Behan Webster [mailto:behanw at converseincode.com]
> Sent: 19 December 2014 20:19
> To: Daniel Sanders; 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 12:07, Daniel Sanders wrote:
> >> -----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.
> Excellent!

Sure enough, it still boots. Updated patch attached. It's not quite as controversial as it was but I've left the do-not-upstream tag on it since I'm fairly certain that kernel upstream will still reject it for slowing down access to the thread context pointer.


> > 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.
> I believe that was the test case which was added due to the changes that
> Renato made for us. So it's no accident that it looks like the
> thread_info case. :)

> >> 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.
> Renato tried to solve the issue for all arches. I'm not sure whether he
> supported the MIPS backend. However, it shouldn't be hard to add that if
> it's missing. Most of the groundwork should already be there.
> >> 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 :-).
> W00t!
> >   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
> gcc *does* promise a lot more. And llvm/clang isn't likely going to ever
> promise the same from what I can tell.
> Our fixing of the named register issues for x86/arm/aarch64 took a very
> long time as a result... The arm patches to fix this were actually just
> merged into mainline this week!

Do you mean linux mainline or llvm/clang mainline? I had a quick look through the latter and didn't manage to spot it.

> Behan
> --
> Behan Webster
> behanw at converseincode.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-DO-NOT-UPSTREAM-mips-Remove-all-instances-of-explici.patch
Type: application/octet-stream
Size: 3038 bytes
Desc: 0002-DO-NOT-UPSTREAM-mips-Remove-all-instances-of-explici.patch
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20141219/4fbe28bd/attachment-0001.obj>

More information about the LLVMLinux mailing list