[LLVMdev] More Encoding Ideas

Chris Lattner sabre at nondot.org
Fri Aug 20 18:43:57 PDT 2004


On Fri, 20 Aug 2004, Robert Mykland wrote:
> >In any case, both signed and unsigned 8-bit constants can be written out
> >in a single byte.  Again, do you think it's worth special casing this
> >though?  Considering that we handle 8-bit strings specially already, there
> >are not a ton of 8-bit constants with value >= 128.
>
> I'd rather that they not be treated specially.  If char defaulted to
> unsigned char, there would be little reason to create this special case.

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.

> >This is a very interesting idea, particularly for languages like C++ that
> >have a ton of types.  Before making this change, I would want to see some
> >numbers though.  In particular, I don't think that types typically take up
> >a large amount of the .bc file size: most of it are instructions.
> >
> >Are you seeing other cases?
>
> No.  This would only save a bit less than two bytes per primitive and
> defined type.  Maybe a few hundred bytes in a large LLVM file.  Not a
> big savings, but a savings.  The thing I like is that along with the
> size savings it appears to make the encode/decode simpler and quicker if
> anything.  So good news all around.

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.

> > > I think the original plan was to have multiple modules in them but this
> > seems
> > > to have gone by the wayside. The result of linking two (or more)
> > modules is a
> > > single module so except in some really bizare corner cases the need for
> > > multiple modules would go away. I suppose we could get rid of the block id
> > > field for the file. I'll give this some thought and see if Chris has any
> > > objections.
> >
> >I don't have any problem with removing it.
>
> Cool. Before you chop remember debug libraries.

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.

-Chris

-- 
http://llvm.org/
http://nondot.org/sabre/




More information about the llvm-dev mailing list