llvm-6502/lib/Bitcode
David Blaikie 93a23a3bd4 Recommit r235458: [opaque pointer type] Avoid using PointerType::getElementType for a few cases of CallInst
(reverted in r235533)

Original commit message:

"Calls to llvm::Value::mutateType are becoming extra-sensitive now that
instructions have extra type information that will not be derived from
operands or result type (alloca, gep, load, call/invoke, etc... ). The
special-handling for mutateType will get more complicated as this work
continues - it might be worth making mutateType virtual & pushing the
complexity down into the classes that need special handling. But with
only two significant uses of mutateType (vectorization and linking) this
seems OK for now.

Totally open to ideas/suggestions/improvements, of course.

With this, and a bunch of exceptions, we can roundtrip an indirect call
site through bitcode and IR. (a direct call site is actually trickier...
I haven't figured out how to deal with the IR deserializer's lazy
construction of Function/GlobalVariable decl's based on the type of the
entity which means looking through the "pointer to T" type referring to
the global)"

The remapping done in ValueMapper for LTO was insufficient as the types
weren't correctly mapped (though I was using the post-mapped operands,
some of those operands might not have been mapped yet so the type
wouldn't be post-mapped yet). Instead use the pre-mapped type and
explicitly map all the types.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235651 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-23 21:36:23 +00:00
..
Reader Recommit r235458: [opaque pointer type] Avoid using PointerType::getElementType for a few cases of CallInst 2015-04-23 21:36:23 +00:00
Writer [opaque pointer types] Serialize the value type for store instructions 2015-04-22 04:14:42 +00:00
CMakeLists.txt
LLVMBuild.txt
Makefile
module.modulemap [modules] Add module maps for LLVM. These are not quite ready for prime-time 2014-05-21 02:46:14 +00:00