search for: allowextraanalysi

Displaying 4 results from an estimated 4 matches for "allowextraanalysi".

Did you mean: allowextraanalysis
2017 May 05
2
Idea for Open Project : Smarter way of dumping LLVM IR with -emit-after-all
> On May 5, 2017, at 8:49 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > > On 05/05/2017 10:44 AM, vivek pandya via llvm-dev wrote: >> Hello LLVM Devs, >> >> I have an idea to improve effectiveness of IR dump with -emit-after-all based on Adam Nemet's 2016 LLVM Dev presentation. >> I think we can track changes in each function, basic block and
2017 Sep 17
2
RFC: Use closures to delay construction of optimization remarks
...e: > > Actually maybe something like: > > 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 a...
2017 Sep 19
0
RFC: Use closures to delay construction of optimization remarks
...ng like: >> >> 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 retur...
2017 Sep 16
3
RFC: Use closures to delay construction of optimization remarks
Another alternative could be: ORE.emitMissed(DEBUG_TYPE, ...) << ... Then the first line of emitMissed does a check if it is 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