We used to mark the free operand as "nocapture", though, arguably, there
is no reason "free" could not put the pointer value in a "free-table",
thereby effectively "capturing" it.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 36973 Build 36972: arc lint + arc unit
Event Timeline
Is there some practical issue I'm missing?
there is no reason "free" could not put the pointer value in a "free-table"
Data structures which are internal to the malloc implementation are considered opaque; otherwise, we couldn't add any attribute markings to malloc.
I should have added my motivation:
I want heap2stack transformation under different circumstances, one of which is:
- whenever all capturing uses of a malloc are in free calls, we can perform the heap2stack transformation (because no one else can know about the pointer).
Now this is a different approach then the one originally proposed by @hfinkel, which was more along the lines of:
- whenever all paths lead *must* lead a free of the pointer (so no unwinding, etc.) we can perform heap2stack
They should catch different cases but the first is easier (IMHO).
The problem now is that non-capturing uses can free the pointer as well.
there is no reason "free" could not put the pointer value in a "free-table"
Data structures which are internal to the malloc implementation are considered opaque; otherwise, we couldn't add any attribute markings to malloc.
Fair point. Though I'm unsure why we need the nocapture here anyway. I guess if it otherwise confuses the alias analysis somehow (which I'm not really sure of in reality) we should consider lifetime markers instead.
I'd rather analyze whether the memory is valid separately from whether the pointer itself is captured, I think? Removing nocapture markings makes all the existing uses of capture analysis weaker.