On 29 March 2014 13:38, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:> I disagree. It is the *easy* part to get many known users to work. This > includes a bunch of kernels, Lisp implementations etc. The rest can be > implemented on top by hand using inline asm, so this is the crucial > part.Let me re-phrase my opinion...>From all discussions on the LLVM list, the one that has shown moreconsistently as a problem was the reservation of allocatable registers. Some background... My original intent was to be able to support the kernel unwinding code. There was a discussion, in which we agree that for that a building stack_pointer would do. But the GCC community has voiced two concerns: there is already a feature for that widely in use, and that feature is more generic. Back to the LLVM list, people were concerned with the implementation and semantics of reserving allocatable registers (yes, we do reserve some of them specially here and there, but this is a generic user-driven module-local reservation mechanism, which can put an unknown strain on the register allocator. Folks agreed, then that a two step implementation would make sense, given the original objectives: first for non-allocatable registers, then a register allocation mechanism could be introduced. I agree that, to make it work like the GCC, reserving registers would be the first thing to implement, but we're not going to support the whole shebang from start, so we can start small. For specifically the non-allocatable ones, named register is as good as the builtin, and that would mean no changes to code that already use it would be necessary, which is always a win. The plan... 0. Map all uses of named register in the kernel: seem to be non-allocatable registers only. 1. Implement named registers for non-allocatable registers 2. Map uses of allocatable registers (libs, dynamic languages, kernels) and make sure there is no other way to do that. 2.a. If there is, do that. 2.b. If not, implement register reservation and expand named register for those classes (this is contentious and why I'm avoiding it for now) cheers, --renato
> On Mar 29, 2014, at 7:27 AM, Renato Golin <renato.golin at linaro.org> wrote: > >> On 29 March 2014 13:38, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: >> I disagree. It is the *easy* part to get many known users to work. This >> includes a bunch of kernels, Lisp implementations etc. The rest can be >> implemented on top by hand using inline asm, so this is the crucial >> part. > > Let me re-phrase my opinion... > > From all discussions on the LLVM list, the one that has shown more > consistently as a problem was the reservation of allocatable > registers. > > Some background... > > My original intent was to be able to support the kernel unwinding > code. There was a discussion, in which we agree that for that a > building stack_pointer would do. But the GCC community has voiced two > concerns: there is already a feature for that widely in use, and that > feature is more generic. > > Back to the LLVM list, people were concerned with the implementation > and semantics of reserving allocatable registers (yes, we do reserve > some of them specially here and there, but this is a generic > user-driven module-local reservation mechanism, which can put an > unknown strain on the register allocator. Folks agreed, then that a > two step implementation would make sense, given the original > objectives: first for non-allocatable registers, then a register > allocation mechanism could be introduced. > > I agree that, to make it work like the GCC, reserving registers would > be the first thing to implement, but we're not going to support the > whole shebang from start, so we can start small. For specifically the > non-allocatable ones, named register is as good as the builtin, and > that would mean no changes to code that already use it would be > necessary, which is always a win. > > The plan... > > 0. Map all uses of named register in the kernel: seem to be > non-allocatable registers only. > 1. Implement named registers for non-allocatable registersI'm not sure if this would work even for non-allocatable registers. I fear this may codegen to a copy from the register and subsequent reads are all of the gpr. Evan> 2. Map uses of allocatable registers (libs, dynamic languages, > kernels) and make sure there is no other way to do that. > 2.a. If there is, do that. > 2.b. If not, implement register reservation and expand named register > for those classes (this is contentious and why I'm avoiding it for > now) > > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 29 March 2014 22:25, Evan Cheng <evan.cheng at apple.com> wrote:>> 1. Implement named registers for non-allocatable registers > > I'm not sure if this would work even for non-allocatable registers. I fear this may codegen to a copy from the register and subsequent reads are all of the gpr.Hi Evan, I'm not sure I follow what GPRs. The plan is to transform all reads from a variable marked "register long foo asm("reg")" into an intrinsic "@llvm.read_register("reg")". If we also want the builtin, that's as easy as mapping "__builtin_stack_pointer()" to "@llvm.read_register("SP")", so the underlying implementation is the same. So: register unsigned long foo asm("SP"); // does nothing long a = foo; // %a = call i32 @llvm.read_register("SP") -> DAG.CopyFromReg("SP") long b = a; // %0 = load %a, store %0, %b (in GPRs, since both a and b are C variables) long c = foo; // %c = call i32 @llvm.read_register("SP") -> DAG.CopyFromReg("SP") In any case, "foo" doesn't exist as a variable in the C level representation (no alloca, etc), and since we can't take the address of it (due to C restrictions), that's fine. If you transfer the values to other variables, in GPRs or in the stack/memory, than all bets are off, and I believe that this is the same in GCC, but *all* reads/writes to named register variables should be represented by read/write intrinsics. cheers, --renato