[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
Fri Nov 17 05:17:39 PST 2017
- Previous message: [llvm-dev] How does LLVM map source lines to machine instructions?
- Next message: [llvm-dev] Ensuring that dead allocations from a custom allocator are killed by LLVM
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 = '' 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>
- Previous message: [llvm-dev] How does LLVM map source lines to machine instructions?
- Next message: [llvm-dev] Ensuring that dead allocations from a custom allocator are killed by LLVM
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]