[PATCH] [opaque pointer type] Bitcode support for explicit type parameter on GEP.

[David Blaikie]

On Wed, Feb 18, 2015 at 2:55 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

> > On 2015-Feb-18, at 13:48, David Blaikie <dblaikie at gmail.com> wrote:
> >
> > Hi chandlerc, dexonsmith, grosbach, resistor,
> >
> > Like http://reviews.llvm.org/D7655, add bitcode support including
> backwards
> > compatibility, for an explicit type parameter to GEP.
> >
> > At the suggestion of Duncan I tried coalescing the two older bitcodes
> into a
> > single new bitcode, though I did hit a wrinkle: I couldn't figure out
> how to
> > create an explicit abbreviation for a record with a variable number of
> > arguments (the indicies to the gep). This means the discriminator between
> > inbounds and non-inbounds gep is a full variable-length field I believe?
> Is my
> > understanding correct? Is there a way to create such an abbreviation?
>
> You can add such an abbreviation by making Array the second last
> element, and making the last element the type in the array.
> Documented here:
>
> http://llvm.org/docs/BitCodeFormat.html#define-abbrev-encoding


Ah, thanks - updated the patch to use this. I'm not sure what array type is
ideal (since it'll be a combination of types and value references - is
there a way to figure out the maximum size I need for those? I know there's
the trick for computing the bit size for type references (& use that for
the pointee type of the gep) but maybe there's a way to do that for value
numbers too, and take the max of the two? Assuming that produces optimal
bit encoding (maybe it's better to use a smaller VBR encoding so we only
pay extra bits for some of the higher indicies? I've no idea))


>
>
> Examples in-tree: `METADATA_NAME` and `TYPE_CODE_FUNCTION`.
>
> > Should I
> > just use two bitcodes as before?
>
> Regardless of the above, I'm interested in others' opinions on this
> (whether two records vs. one record with a discriminator is better).
> I've been preferring the single-record approach myself, purely on
> the principle that it's easier to upgrade in the future by adding
> bits to the discriminator (rather than creating "brand new records").
>

Yeah - certainly open to opinions there.


>
> >
> > http://reviews.llvm.org/D7736
> >
> > Files:
> >  include/llvm/Bitcode/LLVMBitCodes.h
> >  include/llvm/IR/Instructions.h
> >  lib/Bitcode/Reader/BitcodeReader.cpp
> >  lib/Bitcode/Writer/BitcodeWriter.cpp
> >  test/Bitcode/function-encoding-rel-operands.ll
> >  tools/llvm-bcanalyzer/llvm-bcanalyzer.cpp
> >
> > EMAIL PREFERENCES
> >  http://reviews.llvm.org/settings/panel/emailpreferences/
> > <D7736.20218.patch>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150224/8c9abffd/attachment.html>