[LLVMdev] More Encoding Ideas

[Chris Lattner]

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/