[LLVMdev] More Encoding Ideas

Robert Mykland robert at ascenium.com
Mon Aug 23 19:29:13 PDT 2004


At 06:08 PM 8/20/2004, you wrote:
>So, to be explicit, what you're advocating is that:
>
>Even Slot Number:
>         Type = Types[ slot_num / 2 ]
>Odd Slot Number:
>         Type = Pointer[ slot_num / 2 ]
>
>Yes?

Exactly.


>Essentially this eliminates pointer types from the type list altogether.
>Cool idea.
>
>Where's the patch? :)
>
>Seriously though, unless you want to do it, I think I'll probably do
>this sometime before 1.4 is released. The savings are not huge (type
>table is pretty small), but every little bit helps and this will halve
>the number of entries.

Maybe a few hundred bytes for big files.  Go for it.  I'm still trying to 
get my code generator working with 1.3.  With all the optimizations you 
guys did since 0.9, the code is all different, in a good way.  But I have 
to make my code generator smarter to do the simple examples it could do 
before, just because different stuff I don't yet support got used.

>Okay, substitute "BasicBlock" for "label" and I think I get you.  This
>doesn't buy us anything for bytecode file size, but if you need it to
>simplify your implementation, I'd suggest submitting a patch and I'll
>apply it.

OK.

> > Gosh, but at the very least, since it's a special case anyway, we could
> > shrink this field down to a byte.
>
>It will go away in version 1.4.

Good news.

> > >>5) Don't write the compaction table for a function if there are no
> > >>entries.  All my simple examples have empty compaction tables that 
> use up
> > >>8 bytes per function.  This would save space.
> > >
> > >Hmm. That's not supposed to happen.
> >
> > It happens all the time!  I guess this is a bug.
>
>Could you please open a bug report and attach a test case to it? This is
>a serious problem that I need to fix but in order to do that I need a
>reliable test case for repeatability.
>
>Thanks Robert.

Will do.

-- Robert.


Robert Mykland               Voice: (831) 462-6725
Founder/CTO                   Ascenium Corporation 





More information about the llvm-dev mailing list