Opaque Pointer Types: GEP API migrations to specify the gep type explicitly
authorDavid Blaikie <dblaikie@gmail.com>
Tue, 24 Mar 2015 23:34:31 +0000 (23:34 +0000)
committerDavid Blaikie <dblaikie@gmail.com>
Tue, 24 Mar 2015 23:34:31 +0000 (23:34 +0000)
commit4e933df738681d62a70f0e02262d6489eb7d8893
tree932a1e0ad744a1e30457d216e73e022ff6d35651
parent28b71b191749ec8ac0986e0beaa8fc70d3b2e944
Opaque Pointer Types: GEP API migrations to specify the gep type explicitly

The changes to InstCombine (& SCEV) do seem a bit silly - it doesn't make
anything obviously better to have the caller access the pointers element
type (the thing I'm trying to remove) than the GEP itself, but it's a
helpful migration step. This will allow me to more obviously lock down
GEP (& Load, etc) API usage, then fix all the code that accesses pointer
element types except the places that need to be removed (most of the
InstCombines) anyway - at which point I'll need to just remove all that
code because it won't be meaningful anymore (there will be no pointer
types, so no bitcasts to combine)

SCEV looks like it'll need some restructuring - we'll have to do a bit
more work for GEP canonicalization, since it'll depend on how it's used
if we can even manage to canonicalize it to a non-ugly GEP. I guess we
can do some fun stuff like voting (do 2 out of 3 load from the GEP with
a certain type that gives a pretty GEP? Does every typed use of the GEP
use either a specific type or a generic type (i8*, etc)?)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233131 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Analysis/ScalarEvolutionExpander.cpp
lib/Target/NVPTX/NVPTXGenericToNVVM.cpp
lib/Target/R600/AMDGPUPromoteAlloca.cpp
lib/Transforms/InstCombine/InstCombineCasts.cpp
unittests/Linker/LinkModulesTest.cpp