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>
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.) 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/20140730/adadf299/attachment.html>
> 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.It also allows type checking for single initializers. I've been caught out a couple of times when I thought I'd given 17 digits in "let Inst{16-0} = 0b1001000111011010" or similar. Cheers. Tim.
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>
On Thu, Jul 31, 2014 at 12:28 AM, 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 think it would make sense to change this behavior to follow the behavior that Pete describes. I don't have the code handy but my guess is that what the code is doing here is requesting each element in the braces of a bits<n> initializer to be casted to `bit`; in that case, we would want to change that code to first try casting to bits and give that preference (and issues relevant diagnostics). Pete, is that what your patch does? Can you attach your patches? Of course, before changing the behavior, we would probably want to place an assert on that codepath to catch all existing cases where the behavior would change. Also it is important to scan all the docs in docs/TableGen/ and make any necessary updates (if there is nowhere that needs to be updated, then documentation needs to be *added* covering this behavior). Finally, we should post a notice to LLVMdev for out-of-tree maintainers including information about how to add the necessary assert to check for places where this behavior would change their .td files. -- Sean Silva> > Adam > > > Thanks, > Pete > > I.e. I don’t think we currently accept: > > bits<4> x = { opc, opc } > > Thanks, > Adam > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140731/797f0325/attachment.html>
On Thu, Jul 31, 2014 at 12:31 AM, Tim Northover <t.p.northover at gmail.com> wrote:> > 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. > > It also allows type checking for single initializers. I've been caught > out a couple of times when I thought I'd given 17 digits in "let > Inst{16-0} = 0b1001000111011010" or similar. >Allowing underscores in the literal seems like it would help alleviate this somewhat (do we already allow that?). That is what VHDL does ("Underlines can be used to increase readability and have no impact on the value."). -- Sean Silva> > Cheers. > > Tim. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140731/ff3aab2f/attachment.html>