[PATCH] D33688: [Polly] Heap allocation for new arrays

Andreas Simbuerger via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 9 02:03:48 PDT 2017


simbuerg added inline comments.


================
Comment at: lib/CodeGen/IslNodeBuilder.cpp:1430-1434
+      auto *CreatedArray = CallInst::CreateMalloc(
+          &*InstIt, IntPtrTy, SAI->getElementType(),
+          ConstantInt::get(Type::getInt64Ty(Ctx), Size),
+          ConstantInt::get(Type::getInt64Ty(Ctx), ArraySizeInt), nullptr,
+          SAI->getName());
----------------
Meinersbur wrote:
> philip.pfaffe wrote:
> > simbuerg wrote:
> > > Meinersbur wrote:
> > > > Where is the memory free'd?
> > > Good Catch. We just discussed possible locations for the free. The easiest way would be the exit(s) of the SCoP. However, to keep it simple, we would have to do a copy-in/-out to the original array base pointer, right? Everything else (e.g. calculating lexicographic maximal accesses) would give us trouble with non-polyhedral accesses between SCoPs.
> > Couldn't that create use-after-free if the SCoP is within a loop?
> @gareevroman
> I was wrong, the alloca is actually added to the entry block.
> 
> This means that also the `malloc` is in the entry block, but the call to `free` below is added into last block of the //orginal// region (where it is not even used). We either have to
> 
> 1. Add the malloc to the entry block and the free at every `ret` (or non-returning function call)
> 
> - or -
> 
> 2. Add the malloc to the start of the generated code (`polly.start`) and the free at the end of it (`polly.exiting`).
Wait, if you malloc at function entry and free at every ret of the function you will end up with problems in code that can't be modeled as a SCoP because you cannot map to the correct
'last write' in the expanded array that is required for a memory access outside of the SCoP. Therefore, you will have to do copy-in/-out before/after the SCoP to stay correct, hence you can malloc/free right at the SCoP boundary (because you need to do the copying anyway).

Use-After-Free wouldn't become an issue as soon as you malloc/free at the SCoP boundary.


https://reviews.llvm.org/D33688





More information about the llvm-commits mailing list