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

Siddharth Bhat via llvm-dev llvm-dev at lists.llvm.org
Fri Nov 17 05:17:39 PST 2017


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 = '<stdin>'
source_filename = "Module"

; Function Attrs: inaccessiblememonly noinline norecurse nounwind
declare i8* @alloc(i64) local_unnamed_addr #0

; Function Attrs: inaccessiblememonly noinline norecurse nounwind
declare void @useClosure(i8*) local_unnamed_addr #1

; Function Attrs: alwaysinline norecurse nounwind
define void @main() #1 {
entry:
  %closure.raw = tail call noalias i8* @alloc(i64 8)
  %fn_slot = bitcast i8* %closure.raw to void ()**
  store void ()* @"case_ackerman(atom-3 atom-10)_alts", void ()** %fn_slot,
align 8, !invariant.group !0
  tail call void @useClosure(i8* %closure.raw)
  ;========
  ; dead
  %closure.raw.i = tail call noalias i8* @alloc(i64 24)
  %fn_slot.i = bitcast i8* %closure.raw.i to void ()**
  store void ()* @"case_aint()_alts", void ()** %fn_slot.i, align 8,
!invariant.group !0
  ;========
  ret void
}

; Function Attrs: alwaysinline
declare void @"case_aint()_alts"() #2

; Function Attrs: alwaysinline
declare void @"case_ackerman(atom-3 atom-10)_alts"() #2

attributes #0 = { inaccessiblememonly noinline norecurse nounwind writeonly
}
attributes #1 = { alwaysinline norecurse nounwind }
attributes #2 = { alwaysinline }

!0 = distinct !{!0, !"closure_invariant_group"}
-----

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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171117/da096e60/attachment.html>


More information about the llvm-dev mailing list