[LLVMdev] mapping types from a bitcode module
hammacher at cs.uni-saarland.de
Mon Feb 27 09:44:36 PST 2012
since noone of the experts answered, let me share our experiences. We
recently had exactly the same problem, I posted on this list on January
I didn't follow Duncans advice to "just use the linker", since for
several reasons we wanted to have unique struct types even in the
> 1) duplicate the LinkModule internal code and copy the module we load from
> bitcode to a new module with the correct types mapped.
Sounds quite inefficient. If you have to duplicate the internal code
anyway, you can also iterate over the original module and mutateType().
> 2) duplicate BitcodeReader and create a version that reuses existing
> 3) destructively convert all of the types in the imported module to our
> existing types.
That's what we actually implemented, following the idea I described in
the mentioned post. We don't identify identical struct types by their
name, since even in the new type system, names don't actually mean
anything. You could just strip them off.
Instead, we use the pointer value of the types to identify them, since
originally, all our modules reside in the same LLVMContext. Since that
doesn't seem to be the case in your situation, you propably would have
to use the name, or attach other metadata to uniquely identify your structs.
> Also, when loading named StructTypes, would it be possible for LLVM to reuse
> an existing type with the same name assuming the existing type is isomorphic?
> This seems like it would be a win all around.
Just out of interest, I also implemented that, because I thought it
could improve the overall performance. But I couldn't measure any
performance impact on the simple tests in the test-suite.
The main problem is that the named struct could reference other types
defined later in the type table of the module, so you can only check
whether named structs are identical after the whole type table has been
parsed and the types are already created. So during parsing I am
remembering which StructTypes had to be renamed, and after that - but
before parsing the instructions - I check which of them are isomorphic
to the corresponding existing struct, and directly manipulate the type
list used when parsing the rest of the module.
A funny insight when implementing that is that I also had to change the
behaviour of the linker, since it again created copies of all types used
in the source module. So after linking, there again were different
instances of the same struct type, but only one of them had a meaningful
name, since the new copy that the linker creates steals the name of the
original type ;)
For both implementations I can provide source code if you wish.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6392 bytes
Desc: S/MIME Cryptographic Signature
More information about the llvm-dev