[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