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

Behan Webster behanw at converseincode.com
Fri Dec 19 20:18:51 UTC 2014

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.

> 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 :-).

>   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!


Behan Webster
behanw at converseincode.com

More information about the LLVMLinux mailing list