All, I've attached a small patch that adds a new early-clobber operand constraint option to TableGen and would like to get feedback before proceding. As background, the ARM store-exclusive instruction (STREX) stores a success result code in a register operand, and that register cannot be the same register as either the source of the value to be stored, or the base address. Specifically. STREX Rd, Rm, [Rn] // Store Rm to the address contained in Rn, store zero in Rd if successful, one in Rd if not. If Rd == Rm or Rd == Rn, the behaviour is undefined. To model this, we need to be able to specify in the tablegen instruction description that Rd is an early-clobber register so that the allocator will not use the same register for it as for Rm or Rn. The syntax is simple: contraint-list: constraint-list ',' constraint | constraint constraint: '@early' operand | operand '=' operand operand: '$' identifier MachineIntr::addOperand() checks the target instruction description for the constraint when adding register operands and sets IsEarlyClobber if it's present. For a usage example, I've included in the patch the modification to use the constraint for the STREX ARM instruction. Thoughts? Thanks in advance! -Jim -------------- next part -------------- A non-text attachment was scrubbed... Name: early.patch Type: application/octet-stream Size: 5721 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091215/a1c83dd4/attachment.obj>
On Tuesday 15 December 2009 18:01, Jim Grosbach wrote:> For a usage example, I've included in the patch the modification to > use the constraint for the STREX ARM instruction.Your example is: constraints = "@early $success" Why not spell it as: constraints = "$success != $src", "$success != $ptr" The grammar would change to something like: constraint: operand '!=' operand | operand '=' operand This seems more intuitive and more generally applicable. I could see a use for this in other architectures. From reading your example, without the background I wouldn't know what "@early" means. It may be slightly more difficult to code up for TableGen but in the long term it's worth it. -Dave
On Dec 15, 2009, at 5:08 PM, David Greene wrote:> On Tuesday 15 December 2009 18:01, Jim Grosbach wrote: > >> For a usage example, I've included in the patch the modification to >> use the constraint for the STREX ARM instruction. > > Your example is: > > constraints = "@early $success" > > Why not spell it as: > > constraints = "$success != $src", "$success != $ptr" >This was my first thought as well; however, I decided against it. I think it's best, at least for now, to expose an interface in tablegen to express the early-clobber semantics that the back-end already supports rather than adding something completely new. Doing more would require significantly surgery on both tablegen and the register allocation framework to support. The handling of early- clobber register definitions is already in place in the allocator, and this approach simply provides a means of specifying it in the tablegen files. I think that's likely something we'd want separately from a more general purpose solution in any case, as it's analogous to the inline assembler '&' constraint, for example. Do you have specific examples in mind that would be expressible with something more complicated that aren't handleable via an early-clobber constraint?> The grammar would change to something like: > > constraint: operand '!=' operand > | operand '=' operand > > This seems more intuitive and more generally applicable. I could > see a use > for this in other architectures. From reading your example, without > the > background I wouldn't know what "@early" means.Perhaps spelling it out more fully with "earlyclobber" rather than "early" would help? Thanks for the feedback! -Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091215/b5ad25f8/attachment.html>