<div class="gmail_quote">On Fri, May 13, 2011 at 5:11 AM, Dan Bailey <span dir="ltr"><<a href="mailto:drb@dneg.com">drb@dneg.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
That's fine with me. Unless there's a particular reason for it I would suggest perhaps changing the immediate syntax as well to swap it round, so it would be Immi32, Immi64, Immf32, etc. It doesn't bother me that much the way it currently is, but when there are lots of operations taking a register and an immediate, representing them in the same way might be a little more consistent?<br>

<br>
Personally, I think I also might prefer an underscore to make it more readable for new users (Reg_u32, Reg_pred, Imm_i32, Imm_f32, etc). That's maybe just my own preference, so feel free to do it as you've suggested!<br>
<font color="#888888">
<br>
Dan</font></blockquote><div><br></div><div>I've been considering the way registers are represented in the PTX back-end quite a bit lately, and I think we need to re-consider the way we handle registers in the PTX back-end.  As is, we assume a fixed register set of typed and sized registers, which is more-or-less what the LLVM code generation framework expects.  However, PTX is really a special-case target in that the register space is "infinite" and not really typed (yes, PTX allows register types, but I do not believe that is mandatory).  The infinite nature of the register space gives us a few problems:</div>
<div><ol><li>We are currently constrained by the number of registers we specify in PTXRegisterInfo.td</li><li>The LLVM register allocators are not really solving the right problem</li><li>We miss opportunities for register re-use</li>
</ol><div>I'm sure there are more, but those are the ones I am thinking of now.</div></div><div><br></div><div>To solve (1) (and (3) to some degree), I propose we get rid of register types and instead use .b{16, 32, 64} and .pred as our register classes.  I cannot think of a case where specifying a register class (u32, f32, etc.) is required.  In fact, manually modifying my own PTX code to always use .b* registers has not affected anything.  This would both simplify the back-end and allow the LLVM register allocator to re-use registers across different data types (may or may not be a win depending on how good the ptxas register allocator is).</div>
<div><br></div><div>Solving (2) seems to be a much more difficult problem.  The current implementation of register allocation assumes a fixed register space, and allocates registers as best as it can while introducing spill code when it has to.  For PTX, the problem is a bit different.  Instead, we should assume an infinite register space and *minimize* the number of registers required *without* introducing spill code.  It is the responsibility of ptxas to do the final register allocation and spill code creation.  I see two potential solutions to this:</div>
<div><ol><li>Keep the current fixed register space and emit spill code that really just adds an additional register and copies data between registers for spills</li><li>Implement a new register allocation strategy that ties into the existing infrastructure to satisfy our requirements</li>
</ol><div>Solution (1) seems the easiest to implement, but I worry that ptxas may not be able to interpret what is really happening.  I believe doing PTX-level register allocation is at least partially responsible for the speed-ups I have observed when comparing against nvcc-generated code.  That leaves (2) as the preferred method, but I do not know enough about the inner-workings of the LLVM register allocations to properly assess how difficult this would be.</div>
</div><div><br></div><div>Any thoughts?</div><div><br></div><div>By the way, I'm perfectly okay with the name change :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
<br>
Che-Liang Chiou wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
Current register class naming has a confusing prefix letter 'R' (it is<br>
my bad), such as the first 'R' of RRegu32 (for unsigned 32-bit<br>
registers).<br>
<br>
I propose a 'Reg' + type name naming convention for register classes; such as:<br>
  Regu16, Regu32, Regf32, Regf64<br>
With one exception for predicate registers (capitalized first letter of 'pred'):<br>
  RegPred<br>
<br>
Since predicate registers are special in the way that they can't be<br>
passed as arguments or load from/store to memory, I think a little<br>
name convention exception for it is okay.<br>
<br>
What do you think?<br>
<br>
If no objection, I will start making the change.<br>
<br>
Regards,<br>
Che-Liang<br>
<br>
  <br>
</blockquote>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div><br>