You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As title says, people should not have to read through every line of the code to know about such limitations. Especially since the paper talks so much about the importance of handling arrays well, yet never mentions this limitation.
The text was updated successfully, but these errors were encountered:
void visitAlloca(AllocaInst* AI) {
if (AI->isArrayAllocation()) {
... special non-protected case ...
This case is for alloca() and variable-length arrays (VLAs) (in C99). In LLVM terms, this is e.g. alloca i32, i32 size. Calling it stack arrays is misleading; most arrays allocated on stack have constant size, which in LLVM looks like alloca [10 x i32] (array of size ten).
These special cases were triggered only in a couple uninteresting functions, so I didn't feel a pressing need to implement a working solution. But agreed, I should better implement it.
Note for myself: insert additional alloca i32 and make its address as the upper bound of a VLA. This requires knowledge in which direction the stack grows. (How does AddressSanitizer deal with it?!)
Technically speaking, from the IR perspective both representations are fine. I forgot which one the front-end actually uses and it seems that you are right that the ArrayType-based option is the canonical form. Still it is best not to rely on these kind of things, since passes are not required to follow suite. One option is to make sure that the set of InstCombine passes is always executed before this pass (specifically the simplifyAllocaArraySize function in InstCombineLoadStoreAlloca.cpp).
I would also not rely on alloca ordering since too much can happen (including somebody combining the pass with SafeStack without understanding the implications). Why don't you just extend the array with the right size? You already create a brand new alloca for the array. Also be careful with code around allocas, since you can easily end up transforming static allocas into dynamic ones (by having them preceded by instrumentation from a previous alloca).
As title says, people should not have to read through every line of the code to know about such limitations. Especially since the paper talks so much about the importance of handling arrays well, yet never mentions this limitation.
The text was updated successfully, but these errors were encountered: