Displaying 5 results from an estimated 5 matches for "optimizationremark".
2020 Jan 06
2
Question about opt-report strings
...re I understand everything that's in place so my question here may be misguided.
I'm trying to understand the way strings are handled. When a remark is emitted, it seems that the string is constructed on the fly based on streaming inputs. For example,
ORE->emit([&]() {
return OptimizationRemark(DEBUG_TYPE, "LoadElim", LI)
<< "load of type " << NV("Type", LI->getType()) << " eliminated"
<< setExtraArgs() << " in favor of "
<< NV("InfavorOfValue", AvailableValu...
2017 Sep 17
2
RFC: Use closures to delay construction of optimization remarks
...:
>
> if (auto &E = ORE.emitMissed(DEBUG_TYPE)) {
> E.emit(...) << ...;
> }
Well, the point of this interface was exactly to avoid writing a conditional. If you’re willing to use a conditional you can already write this:
if (ORE.allowExtraAnalysis(DEBUG_TYPE))
ORE.emit(OptimizationRemark(…) << …;
But again the point was to hide all this. I find the closure-based interface more concise and easier to identify visually. One reason is that the block is contained within ORE.emit(…). I just wish you could omit the return in a lambda as in Python.
Adam
>
> Credit to Cha...
2017 Sep 19
0
RFC: Use closures to delay construction of optimization remarks
...E.emitMissed(DEBUG_TYPE)) {
>> E.emit(...) << ...;
>> }
>
> Well, the point of this interface was exactly to avoid writing a conditional. If you’re willing to use a conditional you can already write this:
>
> if (ORE.allowExtraAnalysis(DEBUG_TYPE))
> ORE.emit(OptimizationRemark(…) << …;
>
> But again the point was to hide all this. I find the closure-based interface more concise and easier to identify visually. One reason is that the block is contained within ORE.emit(…). I just wish you could omit the return in a lambda as in Python.
>
> Adam
>...
2017 Jul 14
2
Next steps for optimization remarks?
> On Jul 14, 2017, at 10:22 AM, Davide Italiano <davide at freebsd.org> wrote:
>
> On Fri, Jul 14, 2017 at 10:10 AM, Adam Nemet <anemet at apple.com <mailto:anemet at apple.com>> wrote:
>>
>>
>> On Jul 14, 2017, at 8:21 AM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> On Mon, Jun 19, 2017 at 4:13 PM, Brian
2017 Sep 16
3
RFC: Use closures to delay construction of optimization remarks
...s enabled and if not
then returns a dummy stream that does nothing for operator<< (and
short-circuits all the stream operations)
On Sep 15, 2017 2:21 PM, "Adam Nemet via llvm-dev" <llvm-dev at lists.llvm.org>
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-...