Displaying 4 results from an estimated 4 matches for "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 as...
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 return...
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