[LLVMdev] Tablegen binary literals

[Pete Cooper]

On Jul 30, 2014, at 11:28 PM, Adam Nemet <anemet at apple.com> wrote:

> 
> On Jul 30, 2014, at 10:56 PM, Pete Cooper <peter_cooper at apple.com> wrote:
> 
>> 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.
> 
> Looks like bits<n> is already valid in a bits initializer context; it yields the bottom bit.
> 
> def a {
>   bits<2> opc = { 0, 1 };
>   bits<2> opc2 = { 1, 0 };
>   bits<2> oo = { opc, opc2 };
> }
> 
> is valid and produces:
> 
> ..
>   bits<2> oo = { 1, 0 };
> ..
> 
> Are you aware of this?  This may lead to some ambiguity with your proposed extension.  (I have no idea whether this behavior is relied on anywhere though.)
I wasn’t.  This is horrendous.  I traced through the code and it turns out we’ll happily just drop all but the lowest bit in these cases.

I’m going to see what happens if I disallow this, unless of course the variable is a single bit in length.

Thanks for the great example!
Pete
> 
> Adam
> 
>> 
>> 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/20140731/f509a1a7/attachment.html>