llvm dev - May 2017 - Idea for Open Project : Smarter way of dumping LLVM IR with -emit-after-all

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 instructions
by dumping it to YAML files (initially) then track changes done by each
pass incrementally as it is done in optimization remark emitter. Once we
have required information in YAML files we can present it in much readable
way (similar to diff ) through HTML technologies.
I think we can track chances in each entities by giving them a unique
number and that will also map to HTML presentation layer.
However I have not thought if existing ORE framework can be used or not for
this purpose. But if community thinks this is useful then I would like to
work on this.
Also suggest if you can find any problem with this approach.

Sincerely,
Vivek
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170505/f5172a97/attachment.html>

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 
> instructions by dumping it to YAML files (initially) then track 
> changes done by each pass incrementally as it is done in optimization 
> remark emitter. Once we have required information in YAML files we can 
> present it in much readable way (similar to diff ) through HTML 
> technologies.
I think this sounds useful.
> I think we can track chances in each entities by giving them a unique 
> number and that will also map to HTML presentation layer.
> However I have not thought if existing ORE framework can be used or 
> not for this purpose.
I think that we can use ORE for this; I think you'll need some 
infrastructure improvement so that we can emit the remarks from the pass 
managers but not pay the cost of serializing the IR unless something is 
going to use the information.

  -Hal
> But if community thinks this is useful then I would like to work on this.
> Also suggest if you can find any problem with this approach.
>
> Sincerely,
> Vivek
>
>
> _______________________________________________
> 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/20170505/269d077f/attachment.html>

> 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
instructions by dumping it to YAML files (initially) then track changes done by
each pass incrementally as it is done in optimization remark emitter. Once we
have required information in YAML files we can present it in much readable way
(similar to diff ) through HTML technologies.
> 
> I think this sounds useful.
> 
>> I think we can track chances in each entities by giving them a unique
number and that will also map to HTML presentation layer.
>> However I have not thought if existing ORE framework can be used or not
for this purpose.
> 
> I think that we can use ORE for this; I think you'll need some
infrastructure improvement so that we can emit the remarks from the pass
managers but not pay the cost of serializing the IR unless something is going to
use the information.
That is a general feature we just have to have for other remarks too that are
expensive to construct.  See https://bugs.llvm.org/show_bug.cgi?id=32352
<https://bugs.llvm.org/show_bug.cgi?id=32352>.

Vivek, feel free to grab this if you want to work on it.  I can describe the
current situation and we can discuss the design in the PR.

Thanks,
Adam
> 
>  -Hal
> 
>> But if community thinks this is useful then I would like to work on
this.
>> Also suggest if you can find any problem with this approach.
>> 
>> Sincerely,
>> Vivek
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/20170505/72a61462/attachment.html>