[llvm-dev] Commit module to Git after each Pass

[Don Hinton via llvm-dev]

On Thu, Mar 15, 2018 at 2:03 PM, Alexandre Isoard via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> If this is faster than -print-after-all we may actually consider pushing
> that in the code base then? (after diligent code review of course)
>
> Note that it uses the same printing method as -print-after-all:
> - create a pass of the same pass kind as the pass we just ran
> - use Module::print(raw_ostream) to print (except -print-after-all only
> print the concerned part and into stdout)
>
> If there is improvement to be done to print-after-all it might also
> improve git-commit-after-all. (unless that only improve speed when printing
> constructs smaller than module)
>
> In any case, it is, to me, much more usable (and extensible) than
> -print-after-all. But requires git to be in PATH (I'm curious if that works
> on Windows).
>

I don't really have a dog in this fight, but my guess is that this wouldn't
be used that often, so I'm not sure speed is that much of an issue.

I'd considered something similar before, but instead of directly invoking
another tool, e.g., git, I was considering providing a hook mechanism that
would allow users to use whatever they want.

However, post-processing the output via a script seems like the cleanest,
least invasive solution, assuming the deficiencies others have noted could
be addressed.



>
> On Thu, Mar 15, 2018 at 1:35 PM, Daniel Sanders <
> daniel_l_sanders at apple.com> wrote:
>
>> Does https://reviews.llvm.org/D44132 help at all?
>>
>>
>> On 15 Mar 2018, at 09:16, Philip Reames via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> The most likely answer is that the printer used by print-after-all is
>> slow.  I know there were some changes made around passing in some form of
>> state cache (metadata related?) and that running printers without doing so
>> work, but are dog slow.  I suspect the print-after-all support was never
>> updated.  Look at what we do for the normal IR emission "-S" and see if
>> print-after-all is out of sync.
>>
>> Philip
>>
>> On 03/15/2018 08:45 AM, Alexandre Isoard via llvm-dev wrote:
>>
>> Huh. Great! 😁
>>
>> I don't believe my poor excuse from earlier (else we should map all pipes
>> into files!), but I'm curious why we spend less time in system mode when
>> going through file than pipe. Maybe /dev/null is not as efficient as we
>> might think? I can't believe I'm saying that...
>>
>> On Thu, Mar 15, 2018, 08:25 Fedor Sergeev <fedor.sergeev at azul.com> wrote:
>>
>>> Well, git by itself is so focused on performance, so its not surprising
>>> to me that even using git add/git commit does not cause
>>> performance penalties.
>>>
>>
>> Sure, but still, I write more stuff (entire module) into a slower
>> destination (file). Even ignoring git execution time it's counter intuitive.
>>
>> The only difference is that while I write more, it overwrite itself
>> continuously, instead of being a long linear steam. I was thinking of mmap
>> the file instead of going through our raw_stream, but maybe that's
>> unnecessary then...
>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>
>
> --
> *Alexandre Isoard*
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180315/e2b4cd41/attachment.html>