On Fri, 2004-08-20 at 19:10, Chris Lattner wrote:> On Fri, 20 Aug 2004, Reid Spencer wrote: > > > > The only thing it would change is that character constants with values > > > 63 would get encoded in 1 byte instead of 2 (with current > > implementation). I'm making a change that will ALWAYS encode UByteTyID > > and SByteTyID constants in 1 byte which would then render > > -funsigned-char useless (as far as bytecode goes). > > It's 127 right, not 63? Also, what does this have to do with sbyte vs > ubyte?No, its 63. Signed bit takes up one bit and "continue bit" takes up another so signed values 0-63 get the first byte and 64-127 get the second, etc. This has to do with sbyte and ubyte because "char" type gets translated to them.> > > > By "random cruft" you're referring to the current lib/Debugger things > > intermixed with the instructions? > > Hrm, actually, random cruft still might be useful in the future. In > particular, for large scale IPA (millions of LOC programs), you want to be > able to do analysis at compile time, then read just the analysis results > in at link time instead of holding the whole program in memory. Being > able to define additional section ID's later could be useful.Removing the Module ID field doesn't affect that. As Robert pointed out, if we're not done reading the file by the time the "size" field runs out then there's more in the file, either more modules or "random cruft" :) Reid -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040820/64f11190/attachment.sig>
On Fri, 20 Aug 2004, Reid Spencer wrote:> On Fri, 2004-08-20 at 18:43, Chris Lattner wrote: > > > I don't understand what you're getting at here. You can change char to > > default to unsigned right now with llvm-gcc -funsigned-char. I don't > > understand how that would change anything to be more useful though. > > The only thing it would change is that character constants with values > > 63 would get encoded in 1 byte instead of 2 (with current > implementation). I'm making a change that will ALWAYS encode UByteTyID > and SByteTyID constants in 1 byte which would then render > -funsigned-char useless (as far as bytecode goes).It's 127 right, not 63? Also, what does this have to do with sbyte vs ubyte?> > Okay, that's fine. When implementing that, we should take care to create > > the pointer types lazily instead of eagerly to avoid creating pointer > > types that are not used. > > Eww .. you just raised a really good point. I was planning on doubling > the referent type's slot number to get the pointer type. But, if all the > pointer types are not used in the program then this just serves to > increase the numerical values of the slot numbers and it will actually > bloat the size of the file because the vbr_uint written slot numbers > could take more bytes to write.Yes.> Contrary to previous assertions, I'm not going to implement this unless > we can prove that its beneficial.ok.> > I think that debug libraries should be handled in other ways. The > > original idea was to have .bc files hold lots of other random cruft with > > them. With more experience, this seems like a bad idea. > > By "random cruft" you're referring to the current lib/Debugger things > intermixed with the instructions?Hrm, actually, random cruft still might be useful in the future. In particular, for large scale IPA (millions of LOC programs), you want to be able to do analysis at compile time, then read just the analysis results in at link time instead of holding the whole program in memory. Being able to define additional section ID's later could be useful. In any case, shrinking it to one vbr can't hurt. -Chris -- http://llvm.org/ http://nondot.org/sabre/
On Fri, 20 Aug 2004, Reid Spencer wrote:> > It's 127 right, not 63? Also, what does this have to do with sbyte vs > > ubyte? > > No, its 63. Signed bit takes up one bit and "continue bit" takes up > another so signed values 0-63 get the first byte and 64-127 get the > second, etc.Just to clarify, it's actually -64 -> 63 that are one byte values.> Removing the Module ID field doesn't affect that. As Robert pointed out, > if we're not done reading the file by the time the "size" field runs out > then there's more in the file, either more modules or "random cruft" :)Ah, even better! -Chris -- http://llvm.org/ http://nondot.org/sabre/