David Blaikie 62279d8d0a 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. llvm-svn: 235651		2015-04-23 21:36:23 +00:00
..
llvm	Recommit r235458: [opaque pointer type] Avoid using PointerType::getElementType for a few cases of CallInst	2015-04-23 21:36:23 +00:00
llvm-c	[LTO API] add lto_codegen_set_should_internalize.	2015-04-17 17:10:09 +00:00