LLVM is in the process of migrating all of its pointer types from i8*, i32*, etc. to an opaque ptr type, as described here. LLVM 13 takes an important step in that direction, as it is the first LLVM release to include ptr in the LLVM AST. See https://github.com/llvm/llvm-project/commit/2155dc51d700c9fb5f29d79eaacf5e1470e4d8ca. LLVM 15 switches to opaque pointers by default, so this impacts #12.
It's not clear to me what impact this will have on cclyzer++. cclyzer++ creates suballocations based on allocation type, but it seems like alloca still takes the type parameter that cclyzer++ uses to assign types to allocations. Type back-propagation may need minor adjustments to get the type from the load and store instructions themselves, rather than the type of their operand (which will now always be ptr).
Opaque pointers can be disabled through LLVM 15 with -opaque-pointers=1 in opt and -Xclang -no-opaque-pointers for clang.
If there is a big impact, there are at least three ways we could handle this, from trivial to research-grade difficulty:
Default to making allocations have type i8
Use type back-propagation from loads and stores more aggressively
Adopt a memory model that doesn't care so much about types (#112)
LLVM is in the process of migrating all of its pointer types from
i8*,i32*, etc. to an opaqueptrtype, as described here. LLVM 13 takes an important step in that direction, as it is the first LLVM release to includeptrin the LLVM AST. See https://github.com/llvm/llvm-project/commit/2155dc51d700c9fb5f29d79eaacf5e1470e4d8ca. LLVM 15 switches to opaque pointers by default, so this impacts #12.It's not clear to me what impact this will have on cclyzer++. cclyzer++ creates suballocations based on allocation type, but it seems like
allocastill takes the type parameter that cclyzer++ uses to assign types to allocations. Type back-propagation may need minor adjustments to get the type from theloadandstoreinstructions themselves, rather than the type of their operand (which will now always beptr).Opaque pointers can be disabled through LLVM 15 with
-opaque-pointers=1inoptand-Xclang -no-opaque-pointersforclang.If there is a big impact, there are at least three ways we could handle this, from trivial to research-grade difficulty:
i8loads andstores more aggressively