[llvm-dev] RFC: Use closures to delay construction of optimization remarks

[Hal Finkel via llvm-dev]

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>