[llvm-dev] Ensuring that dead allocations from a custom allocator are killed by LLVM (original) (raw)

Siddharth Bhat via llvm-dev llvm-dev at lists.llvm.org
Wed Nov 29 15:57:32 PST 2017

Thanks for the pointer!

On Wed 29 Nov, 2017, 18:50 Philip Reames, <listmail at philipreames.com> wrote:

There are no existing attributes for this in upstream, but you can hook isAllocLikeFunction to get the effect you're looking for.

Philip On 11/17/2017 05:17 AM, Siddharth Bhat via llvm-dev wrote: Hello all, I have a custom allocator, and would like to teach LLVM about its semantics. In particular, I would like LLVM to kill allocations that are "dead", similar to dead new in C++. Consider this example: ; ModuleID = '' sourcefilename = "Module" ; Function Attrs: inaccessiblememonly noinline norecurse nounwind declare i8* @alloc(i64) localunnamedaddr #0 ; Function Attrs: inaccessiblememonly noinline norecurse nounwind declare void @useClosure(i8*) localunnamedaddr #1 ; Function Attrs: alwaysinline norecurse nounwind define void @main() #1 { entry: %closure.raw = tail call noalias i8* @alloc(i64 8) %fnslot = bitcast i8* %closure.raw to void ()** store void ()* @"caseackerman(atom-3 atom-10)alts", void ()** %fnslot, align 8, !invariant.group !0 tail call void @useClosure(i8* %closure.raw) ;======== ; dead %closure.raw.i = tail call noalias i8* @alloc(i64 24) %fnslot.i = bitcast i8* %closure.raw.i to void ()** store void ()* @"caseaint()alts", void ()** %fnslot.i, align 8, !invariant.group !0 ;======== ret void } ; Function Attrs: alwaysinline declare void @"caseaint()alts"() #2 ; Function Attrs: alwaysinline declare void @"caseackerman(atom-3 atom-10)alts"() #2 attributes #0 = { inaccessiblememonly noinline norecurse nounwind writeonly } attributes #1 = { alwaysinline norecurse nounwind } attributes #2 = { alwaysinline } !0 = distinct !{!0, !"closureinvariantgroup"} ----- In my view, %closure.raw.i is a dead allocation, because the memory returned by it is not used anywhere. How do I communicate this fact to LLVM? I tried seeing how clang does it, but I'm not sure - it doesn't seem to have any attribute that would help, except perhaps builtin. Does LLVM know about the special semantics of new? Cheers, ~Siddharth. -- Sending this from my phone, please excuse any typos!

LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- Sending this from my phone, please excuse any typos! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171129/43b4d2b1/attachment.html>

More information about the llvm-dev mailing list