<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 03/16/2017 06:24 PM, Mehdi Amini via
cfe-dev wrote:<br>
</div>
<blockquote
cite="mid:AC120966-00FC-477E-A084-20567A3BE6A3@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Mar 16, 2017, at 4:22 PM, Mehdi Amini via
llvm-dev <<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<blockquote type="cite" style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;" class=""><br
class="Apple-interchange-newline">
On Mar 16, 2017, at 10:29 AM, Roger Ferrer Ibanez via
llvm-dev <<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>>
wrote:<br class="">
<br class="">
Hi all,<br class="">
<br class="">
I'm implementing interleaved source in assembly output.
Early reviews raised the concern<br class="">
</blockquote>
<br style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; float: none; display:
inline !important;" class="">Is there a patch up for
review?</span><br style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; float: none; display:
inline !important;" class="">I’m wondering how is the
frontend enabling this interleaved output mode?</span><br
style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;" class="">
<br style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;" class="">
<blockquote type="cite" style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;" class="">that the current
implementation will be opening files (using a
llvm::MemoryBuffer) that are likely to be in the memory of
the front end (commonly clang but I think we want this to
be front end agnostic).<span class="Apple-converted-space"> </span><br
class="">
</blockquote>
</div>
</blockquote>
<div><br class="">
</div>
<div>If we mmap files, is it a problem if a process mmap two
times the same file? I was assuming this to be “free”. (I’d
like to make sure there is a real issue to solve here).</div>
</div>
</blockquote>
<br>
I agree, the cost of that should be low. I believe the concern
raised on the review revolved around files that don't really exist
on the file system, such as code piped in on STDIN (or things
otherwise provided through the VFS layer).<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:AC120966-00FC-477E-A084-20567A3BE6A3@apple.com"
type="cite">
<div>
<div><br class="">
</div>
<div>— </div>
<div>Mehdi</div>
<div><br class="">
</div>
<div><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<blockquote type="cite" style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;" class=""><br class="">
I'm now exploring ideas to avoid reopening files and let
LLVM reuse the files the FE had to open.<br class="">
<br class="">
I am assuming that the front end will use
llvm::MemoryBuffer (e.g.: clang does indirectly through
clang::SourceManager).<br class="">
<br class="">
So for buffers related to named files (including stdin,
which does not have name and is handled in a special way)
we could have in the LLVM context a MemoryBufferRegistry.
The idea is to add new creators of MemoryBuffer (the ones
that work on named files and stdin) that can be passed a
reference to that llvm::MemoryBufferRegistry. MemoryBuffer
objects would register/deregister themselves at
creation/destruction. This registry can then be used as a
cache of already opened files from which retrieve a
reference to the MemoryBuffer itself using the file path.
These new interfaces would be opt-in for all users of
MemoryBuffer.<br class="">
<br class="">
Back to my case, the new AsmPrinterHandler could now use
the MemoryBufferRegistry of the LLVM context. If there is
none or the memory buffer associated to a file path has
been already deregistered (or was never registered e.g.
because we are using a .ll file directly), it would open
the file as usual, otherwise it would reuse the registered
MemoryBuffer.<br class="">
<br class="">
I see a few downsides of this approach, though.<br
class="">
<br class="">
It overlaps a bit with the existing SourceManager in clang
which already does some caching work through the
clang::ContentCache class. At first the cache seems hard
to abstract away as it uses clang::FileEntry and looks
pretty tailored for clang needs.<br class="">
<br class="">
Also, assuming that the front end is using a MemoryBuffer
may be a too strong requirement, in particular for FE's
that are mostly unaware of LLVM except for a final LLVM
codegen pass. This would mean that the files would be
reopened even if they are already in the memory of the FE.<br
class="">
<br class="">
Finally the file path may not even be a good identifier to
reuse MemoryBuffer objects.<br class="">
<br class="">
Thoughts?<br class="">
<br class="">
Thank you,<br class="">
Roger<br class="">
<br class="">
_______________________________________________<br
class="">
LLVM Developers mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br
class="">
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></blockquote>
</div>
</blockquote>
</div>
<br class="">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>