[PATCH] Tablegen binary literals should be sized

Eric Christopher echristo at gmail.com
Thu Jul 31 14:36:01 PDT 2014


If you could document algorithm in (I think it's) patch 4 where you
then reverse the list of bits?

Otherwise LGTM and thanks for doing the work, it's a nice improvement.

-eric

On Thu, Jul 31, 2014 at 1:48 PM, Pete Cooper <peter_cooper at apple.com> wrote:
> Hi all
>
> Moving this from LLVMDev
> (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/075223.html) now that
> i have patches i’d welcome reviews of.  The following is the initial summary
> from that email thread.
>
> "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.”
>
>
> For those interested in the low level details, i’ve changed binary literals
> such as 0b011 from creating an integer ‘3’, to creating a BitsInit ‘{ 0, 1,
> 1}’.  As Sean suggested, this was better than introducing yet another type
> just for binary literals.
>
> As part of this, BitsInit values now had to be able to be typed.  This is
> because we had uses of binary literals which expected to be typed (for
> example list<bits<2>> [0b00, 0b01]).  I’ve moved BitsInit from being a
> subclass of Init to a subclass of TypedInit to allow this.
>
> Note that patches 2 and 3 really need to be committed together.  I can
> squash them before commit, but just wanted to present the changes
> independently.
>
> Patch 5 can also be committed without any of the others, but just shows that
> this did actually catch some useful cases where we mismatched sizes of
> binary expressions.
>
> Thanks,
> Pete
>
>
>
>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>




More information about the llvm-commits mailing list