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

Philip Pfaffe via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 8 08:48:26 PDT 2017


philip.pfaffe added inline comments.


================
Comment at: lib/CodeGen/IslNodeBuilder.cpp:1424
+      // Get the 'int' pointer
+      auto IntPtrTy = Type::getInt64Ty(Ctx);
+
----------------
simbuerg wrote:
> philip.pfaffe wrote:
> > simbuerg wrote:
> > > Question for my own understanding: We can pin this to 64bits only if we know which malloc implementation we have available on the target machine, right?
> > Why not get the real IntPtrTy from the current DataLayout?
> Well it's not the problem that we don't know the size of the IntPtr. We don't know the argument type that the system's malloc function expects (whatever size_t might be on the target).
> 
> Normally you would expect 'unsigned int', then we could just get the size from the DataLayout.
> By default CreateMalloc would generate a call to 'void malloc(IntPtrTy)'.
You are right of course. There is no way to obtain the real `size_t` in the middle end.

I don't have a strong opinion on this, but I'd consider IntPtrTy to be the better default over hard-coding some int type, as AFAICS (u)intptr_t and size_t are the same on basically all platforms.


================
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());
----------------
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?


https://reviews.llvm.org/D33688





More information about the llvm-commits mailing list