AliveToolkit
new semantics for object size
This is going to be a nightmare.. we need to predict the future to evaluate gep inbounds. Not clear if it's path sensitive or not, but it precludes the construction of a precise step-by-step interpreter regardless. https://github.com/llvm/llvm-project/pull/141338
This is going to be a nightmare.. we need to predict the future to evaluate gep inbounds. Not clear if it's path sensitive or not, but it precludes the construction of a precise step-by-step interpreter regardless. llvm/llvm-project#141338
The wording explicitly does not require predicting the future. GEP inbounds for growable allocations always refers to the maximum possible allocation size, independently of what maximum size it will actually reach.
Yeah, an exact interpreter gets the max object size as an input. For the "native" allocation operations LLVM understands (alloca, malloc), max size == initial size.
One thing that needs clarification in LangRef is what kind of memory() function attributes allow a function to increase the size of a block.
One thing that needs clarification in LangRef is what kind of
memory()function attributes allow a function to increase the size of a block.
I'd assume that growing an object would count as a write effect on that object, so you'd need whatever contains that (e.g. argmem: write if passed via argument).
One thing that needs clarification in LangRef is what kind of
memory()function attributes allow a function to increase the size of a block.I'd assume that growing an object would count as a write effect on that object, so you'd need whatever contains that (e.g. argmem: write if passed via argument).
I'm ok with that. But that can potentially block optimizations because a function that just extends the object size doesn't change the memory contents. But maybe it doesn't matter in practice.
My initial confusion was because we usually tag allocation functions with inaccessible, but that wouldn't be sufficient here.
One thing that needs clarification in LangRef is what kind of
memory()function attributes allow a function to increase the size of a block.I'd assume that growing an object would count as a write effect on that object, so you'd need whatever contains that (e.g. argmem: write if passed via argument).
I'm ok with that. But that can potentially block optimizations because a function that just extends the object size doesn't change the memory contents. But maybe it doesn't matter in practice.
Yeah, I don't think trying to distinguish write vs grow is going to be particularly valuable, as LLVM isn't going to be able to analyze these allocations particularly well anyway, and growing an allocation should be irrelevant in most context.
For shrinking an allocation (not allowed currently) we should consider "shrink" as a type of "free" for the purposes of nofree.