Hi all
Currently tablegen parses binary literals such as 0b011 and immediately turns
them in to integers internally. Due to this, 0b011 is a 2-bit value because
tablegen will happily drop leading zeroes on integers.
I propose that we change this, and store binary literals with a size. I think
this is much more natural, as when the user writes a value with 3 bits, I think
they expect to get a value with 3 bits, and not a 2-bit value which is silently
truncated and later silently zero extended.
Given this, I would then like to extend bits initializers to accept these new
sized binary literals. For example, I would like to be able to write
bits<2> opc;
bits<8> x = { opc, 0b1100, rd{1}, rs{0} }
This would let us write some encodings much more concisely, instead of having to
put each initializer on its own line.
I do have patches, which I’m happy to present for review, but I’d like some
feedback on the general idea before we get to the low level details.
Thanks,
Pete
On Jul 30, 2014, at 7:05 PM, Pete Cooper <peter_cooper at apple.com> wrote:> Hi all > > Currently tablegen parses binary literals such as 0b011 and immediately turns them in to integers internally. Due to this, 0b011 is a 2-bit value because tablegen will happily drop leading zeroes on integers. > > I propose that we change this, and store binary literals with a size. I think this is much more natural, as when the user writes a value with 3 bits, I think they expect to get a value with 3 bits, and not a 2-bit value which is silently truncated and later silently zero extended. > > Given this, I would then like to extend bits initializers to accept these new sized binary literals. For example, I would like to be able to write > > bits<2> opc; > bits<8> x = { opc, 0b1100, rd{1}, rs{0} } > > This would let us write some encodings much more concisely, instead of having to put each initializer on its own line.Hi Pete, Just to clarify, are you proposing two things here? First, 0b… literals to have type bits<n> and second to allow bits<n> initializer to contain other bits<m> elements which would initialize the next m elements. I.e. I don’t think we currently accept: bits<4> x = { opc, opc } Thanks, Adam> I do have patches, which I’m happy to present for review, but I’d like some feedback on the general idea before we get to the low level details. > > Thanks, > Pete > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi Adam> On Jul 30, 2014, at 10:28 PM, Adam Nemet <anemet at apple.com> wrote: > > Hi Pete, > > Just to clarify, are you proposing two things here? First, 0b… literals to have type bits<n> and second to allow bits<n> initializer to contain other bits<m> elements which would initialize the next m elements. >Yeah, exactly those 2 things. I have them in separate patches, but I think we only get the benefit from sized binary literals if we also allow them to initialize multiple bits in another bits<n> type. Thanks, Pete> I.e. I don’t think we currently accept: > > bits<4> x = { opc, opc } > > Thanks, > Adam-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140730/6b7396ac/attachment.html>