Adam Nemet via llvm-dev
2017-Sep-15 21:21 UTC
[llvm-dev] RFC: Use closures to delay construction of optimization remarks
For better readability we typically create remarks and call OptimizationRemarkEmitter::emit unconditionally. E.g.: Transforms/IPO/Inliner.cpp: ORE.emit(OptimizationRemarkMissed(DEBUG_TYPE, "TooCostly", Call) Transforms/IPO/Inliner.cpp- << NV("Callee", Callee) << " not inlined into " Transforms/IPO/Inliner.cpp- << NV("Caller", Caller) << " because too costly to inline (cost=" Transforms/IPO/Inliner.cpp- << NV("Cost", IC.getCost()) Transforms/IPO/Inliner.cpp- << ", threshold=" << NV("Threshold", IC.getThreshold()) << ")"); Then inside ORE we return right away if the remarks for the given pass is not enabled. This is nice and concise however there is still some overhead involved in this if remarks are not enabled: 1. Constructing the remark object 2. Computing and inserting the strings, named-value arguments 3. Performing the comparison between the pass name and the passes enabled by the user 4. Virtual destructor Now that Vivek added support for asking LLVMContext for what remarks are enabled by the user [1] we can improve this. The idea is to allow ORE::emit to take a closure. This delays all this work until we know remarks are enabled. E.g. the above code with closure: ORE.emit([&]() { return OptimizationRemarkMissed(DEBUG_TYPE, "TooCostly", Call) << NV("Callee", Callee) << " not inlined into " << NV("Caller", Caller) << " because too costly to inline (cost=" << NV("Cost", IC.getCost()) << ", threshold=" << NV("Threshold", IC.getThreshold()) << ")"; }); I have a proof-of-concept implementation at https://reviews.llvm.org/D37921 <https://reviews.llvm.org/D37921>. The main change is that since in the lambda the remark is now returned by value, we need to preserve its type in the insertion operator. This requires making the insertion operator generic. I am also curious if people see C++ portability problems with the code. Feedback welcome. Adam [1] https://reviews.llvm.org/D33514 <https://reviews.llvm.org/D33514> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170915/0c55efb6/attachment-0001.html>
Hal Finkel via llvm-dev
2017-Sep-16 01:33 UTC
[llvm-dev] RFC: Use closures to delay construction of optimization remarks
On 09/15/2017 04:21 PM, Adam Nemet via llvm-dev wrote:> For better readability we typically create remarks and call > OptimizationRemarkEmitter::emit unconditionally. E.g.: > > Transforms/IPO/Inliner.cpp: > ORE.emit(OptimizationRemarkMissed(DEBUG_TYPE, "TooCostly", Call) > Transforms/IPO/Inliner.cpp- << NV("Callee", Callee) << " > not inlined into " > Transforms/IPO/Inliner.cpp- << NV("Caller", Caller) << " > because too costly to inline (cost=" > Transforms/IPO/Inliner.cpp- << NV("Cost", IC.getCost()) > Transforms/IPO/Inliner.cpp- << ", threshold=" << > NV("Threshold", IC.getThreshold()) << ")"); > > Then inside ORE we return right away if the remarks for the given pass > is not enabled. > > This is nice and concise however there is still some overhead involved > in this if remarks are not enabled: > > 1. Constructing the remark object > 2. Computing and inserting the strings, named-value arguments > 3. Performing the comparison between the pass name and the passes > enabled by the user > 4. Virtual destructor > > Now that Vivek added support for asking LLVMContext for what remarks > are enabled by the user [1] we can improve this. The idea is to allow > ORE::emit to take a closure. This delays all this work until we know > remarks are enabled. E.g. the above code with closure: > > ORE.emit(*[&]() {* > *return* OptimizationRemarkMissed(DEBUG_TYPE, "TooCostly", Call) > << NV("Callee", Callee) << " not inlined into " > << NV("Caller", Caller) << " because too costly to inline > (cost=" > << NV("Cost", IC.getCost()) > << ", threshold=" << NV("Threshold", IC.getThreshold()) > << ")"*;* > * }*); >Makes sense to me. This will also give us a more-natural way to deal with constructing remarks where the remark construction itself is potentially expensive (e.g., involves doing some extra analysis or traversing data structures). -Hal> > I have a proof-of-concept implementation at > https://reviews.llvm.org/D37921. > The main change is that since in the lambda the remark is now returned > by value, we need to preserve its type in the insertion operator. > This requires making the insertion operator generic. I am also > curious if people see C++ portability problems with the code. > > Feedback welcome. > > Adam > > [1] https://reviews.llvm.org/D33514 > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170915/0dd809be/attachment.html>