<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Hi Dinesh,</div><div class=""><br class=""></div><div class="">Thanks for the questions / thoughts! (Just back after being out-of-office for a bit...)</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1;"><div class="" style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;">Are you planning to extend similar support for LLD in future?</div></div></blockquote><div class=""><br class=""></div>I probably won't work on that myself since we're not using LLD in our toolchain, but once the generic support has landed in LLVM it should be just as easy for LLD to use it as for Clang.<br class=""><div><br class=""></div><div><blockquote type="cite" class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1;"><ol start="1" type="1" class="" style="margin-bottom: 0in; margin-top: 0in;"><li class="MsoListParagraph" style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;">The capability of deleting directories is not available. Applications use temp directories for compilation and it will be good to delete them.</li></ol></div></blockquote></blockquote><br class=""></div><div>Hmm, interesting use case.</div><div><br class=""></div><div>Sam and I are both hoping to support OutputBackends that are write-only (no reading), which conflicts with the temp-directory usage model (if the app is going to delete the temp directory, then I assume it also needs to read from it?).</div><div><br class=""></div><div>There might be a clean way to support this (virtualizing the idea of a read/write temp directory), but I need to think a bit more. I wonder, can you be more specific about the usage model you have in mind?</div><div><br class=""></div><div><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">The generated unique names when going through StableUniqueEntityHelper follows a predictable series of names unlike current implementation in LLVM which generates random names. This could pose a challenge in a scenario where application is performing repeated compilations each using separate Output backends.<br class=""></blockquote></blockquote></div><br class=""></div><div>Good point. For the OnDiskOutputBackend, we could default to non-stable / random names; for other backends, I prefer the assumption that the compilation is being done in isolation... but a backend that wants to coordinate better is free to do so. Does that make sense to you?</div><div><br class=""></div><div><div class="">Duncan</div></div><div><br class=""><blockquote type="cite" class=""><div class="">On 2021 Mar 5, at 08:10, Bhaskaran, Dineshkumar (MLSE) <<a href="mailto:Dineshkumar.Bhaskaran@amd.com" class="">Dineshkumar.Bhaskaran@amd.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; 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; text-decoration: none;"><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Hi Duncan,<span class="Apple-converted-space"> </span><o:p class=""></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Thanks for this work. At AMD we were working on similar lines for a use case that requires entire process of compilations and linking to be done in-memory. The approach we were following was introducing write capability in LLVM VFS and use it with compiler outputs. This patch allows us to have in-memory compilations. I have two observations from the point of view of the use case above (I am not sure if it makes sense to have it here)<o:p class=""></o:p></div><ol start="1" type="1" style="margin-bottom: 0in; margin-top: 0in;" class=""><li class="MsoListParagraph" style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;">The capability of deleting directories is not available. Applications use temp directories for compilation and it will be good to delete them.<o:p class=""></o:p></li><li class="MsoListParagraph" style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;">The generated unique names when going through StableUniqueEntityHelper follows a predictable series of names unlike current implementation in LLVM which generates random names. This could pose a challenge in a scenario where application is performing repeated compilations each using separate Output backends.<o:p class=""></o:p></li></ol><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Are you planning to extend similar support for LLD in future?<o:p class=""></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Thanks,<o:p class=""></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Dinesh<o:p class=""></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(225, 225, 225); padding: 3pt 0in 0in;" class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class="">From:</b><span class="Apple-converted-space"> </span>llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" style="color: blue; text-decoration: underline;" class="">llvm-dev-bounces@lists.llvm.org</a>><span class="Apple-converted-space"> </span><b class="">On Behalf Of<span class="Apple-converted-space"> </span></b>Sam McCall via llvm-dev<br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Monday, February 22, 2021 7:41 PM<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" style="color: blue; text-decoration: underline;" class="">dexonsmith@apple.com</a>><br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span>LLVM Dev <<a href="mailto:llvm-dev@lists.llvm.org" style="color: blue; text-decoration: underline;" class="">llvm-dev@lists.llvm.org</a>>; CFE Dev <<a href="mailto:cfe-dev@lists.llvm.org" style="color: blue; text-decoration: underline;" class="">cfe-dev@lists.llvm.org</a>><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [llvm-dev] [cfe-dev] RFC: Add an llvm::vfs::OutputManager to allow Clang to virtualize compiler outputs<o:p class=""></o:p></div></div></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">[CAUTION: External Email]<span class="Apple-converted-space"> </span><o:p class=""></o:p></div><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Sorry about the long delay!<o:p class=""></o:p></div></div><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">This looks<span class="Apple-converted-space"> </span><b class="">much</b> better to me, thank you for the simplifications!<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I've made a bunch of notes on the patch itself which I'll send now too. High-level things inline: TL;DR: stream/buffer confusion in outputfile, scope.<o:p class=""></o:p></div></div></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">On Wed, Feb 10, 2021 at 3:12 AM Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" style="color: blue; text-decoration: underline;" class="">dexonsmith@apple.com</a>> wrote:<o:p class=""></o:p></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Sam, any thoughts here?<o:p class=""></o:p></div><div class=""><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">On 2021 Feb 2, at 19:36, Duncan P. N. Exon Smith via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" style="color: blue; text-decoration: underline;" class="">llvm-dev@lists.llvm.org</a>> wrote:<o:p class=""></o:p></div></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Update: I've incorporated much of Sam's feedback into the main patch (</span><a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD95501&data=04%7C01%7Cchristudasan.devadasan%40amd.com%7C96736b89f9da4e9af05b08d8d73bd23d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637495999244979615%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9lilI5QLjv6pBsRJaSKvbiKfBNLmMO69K7D46rMaApg%3D&reserved=0" target="_blank" style="color: blue; text-decoration: underline;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">https://reviews.llvm.org/D95501</span></a><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">).</span><o:p class=""></o:p></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Simplify OutputConfig, restricting it to semantic information about a specific output. Sink all backend configuration to flags on the backends themselves.<o:p class=""></o:p></span></div></div></div></div></div></blockquote></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">The remaining options look great, and agree that we can't expect everything to be configured globally.<o:p class=""></o:p></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Remove OutputManager, instead exposing OutputBackend directly.<o:p class=""></o:p></span></div></div></div></div></div></blockquote></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Hooray! <o:p class=""></o:p></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Merge Output and OutputDestination into a single class called OutputFile, and rename the API for creating them to OutputBackend::createFile().<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Add support for working directories via OutputDirectory, and add OutputBackend::getDirectory() and OutputBackend::createDirectory().<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Add support for createUniqueFile() and createUniqueDirectory(), both heavily used in clang. Backends without read access can use StableUniqueEntityAdaptor to implement these.<o:p class=""></o:p></span></div></div></div></div></div></blockquote></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">This is definitely needed, but there are a few design options and I can't say I precisely understand either the requirements or the solution in the patch.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I think it would be useful to review this separately. <o:p class=""></o:p></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">The main thing not settled is the threading guarantees. Restating the straw man I proposed:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- All OutputBackend APIs are safe to call concurrently. Since OutputDirectory *is* an OutputBackend, it can be used concurrently as well.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- An OutputFile cannot be used concurrently, but two files from the same backend can be.<o:p class=""></o:p></span></div></div></div></div></div></blockquote></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">LGTM <o:p class=""></o:p></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Interested in everyone's thoughts on that; if that sounds reasonable I can update the patch to make it so.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div class=""><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Two other points:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Sam proposed dropping OutputConfig. I don't think we can, as the API client needs to communicate semantic information about specific outputs, not about the backends generally.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Sam suggested OutputDestination (now OutputFile) seemed bloated. I talked through some of the details in my previous response; most of the complexity is there to make MirroringOutputBackend work efficiently and avoid duplication in subclasses. As a counterpoint, the only API a concrete subclass needs to override is storeContentBuffer().<o:p class=""></o:p></span></div></div></div></div></div></div></div></div></div></blockquote></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Hmm, OutputFile still feels caught between two concepts: a buffer-based one and a stream based one.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I understand the goal to make this easy to implement and easy to use, but having a lot of conceptual distance between the two, and optional methods/implementation strategies is easy to misunderstand.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I may have missed it (apologies if so), but is there somewhere a breakdown of which performance-critical configurations this is aimed at?<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">(e.g. many small outputs that don't benefit from streaming, mirrored to two output streams, but one is null)<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Performance is certainly going to cut against simplicity sometimes, but it's hard to evaluate without knowing what we're optimizing for.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> > MirroringOutputBackend work efficiently<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">One thing I don't understand about MirroringOutputBackend - why does it buffer the content? It seems possible to create a raw_pwrite_stream that broadcasts to raw_pwrite_streams of the underlying outputs.<o:p class=""></o:p></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Sam, let please take another look and let me know if you have more high-level comments.<o:p class=""></o:p></span></div></div></div></div></blockquote></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Only other thing is the scope of the patch - it's useful that as an RFC it's comprehensive and shows things fitting together.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">But the amount of detail is a bit overwhelming :-)<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I think the parts regarding directories, unique files, mirroring/filtering backends, many of the output options would be easier to review in detail in isolated patches.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Others, if you have feedback, please let me know!<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Thanks!<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Duncan<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div class=""><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">On 2021 Jan 28, at 11:24, Duncan P. N. Exon Smith via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" style="color: blue; text-decoration: underline;" class="">llvm-dev@lists.llvm.org</a>> wrote:<o:p class=""></o:p></span></div></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div><div class=""><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Thanks for the detailed response Sam!<o:p class=""></o:p></span></div></div><div class=""><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></p><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">This roughly corresponds to OutputBackend + OutputDestination in the patch, except:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""> - the OutputConfig seems like it belongs to particular backends, not the overall backend abstraction<o:p class=""></o:p></span></div></div></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Ideally the OnDiskOutputConfig would almost entirely be settings on OnDiskOutputBackend since no one else will care. It isn't that way in the initial patch because Clang decides most of this stuff on a per-output basis. Maybe there's a refactoring that could fix it.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Here are the problems I hit that led to this design:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">1. Some properties need to be associated with specific outputs, not backends, because they relate to properties of the outputs themselves. Here are two:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- ClientIntentOutputConfig::NeedsSeeking<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- OnDiskOutputConfig::OpenFlagText<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Maybe also something like:<o:p class=""></o:p></span></div></div><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- OnDiskOutputConfig::CreateDirectories<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">(and maybe others)<o:p class=""></o:p></span></div></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">I couldn't think of a good way to solve this besides passing in configuration at output creation time.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">2. Some "configurers" may be handed a pre-constructed opaque OutputManager / OutputBackend and need to configure internal OnDiskOutputBackend. In particular, I found that some tooling wants to turn off:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- OnDiskOutputConfig::RemoveFileOnSignal<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">(others flags might benefit)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">This is "documented" by the call chains of clang::CompilerInstance::createOutputFile.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">I reused the solution from #1 since it needed (?) to exist anyway. Another option would be to add an OutputBackend visitor, to find and reconfigure any "contained" OnDiskOutputBackend. This seems pretty heavyweight though.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""> - OutputDestination has a lot of stuff in it, I'll need to dig further into the patch to try to understand why<o:p class=""></o:p></span></div></div></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Firstly, `Output` has the user-facing abstraction. `OutputDestination` has low-level bits. Another reasonable name might be `OutputImpl` but `OutputDescription` seemed more descriptive.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Secondly, most of the low-level bits avoid unnecessary copies of content buffers. Maybe there are simpler ideas for how to do this, but here are the design goals I was working around:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Avoid buffering content unless necessary.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Avoid duplicating content buffers unless necessary.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Support multiple destinations (for mirrored backends) without breaking the above rules. The obvious "interesting" case is in-memory + on-disk (in either order).<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Make sub-classes of `OutputDestination` as small as possible given the above.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Thirdly, there's some boilerplate related to lifetimes of multiple destinations. Probably having an explicit `MirroringOutputDestination` would be better.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">As for OutputManager itself, I think this belongs in clang, if it's needed. Its main job seems to be to store a set of default options and manage the lifecycle of backends, and it's not obvious that those sorts of concerns will generalize across tools or that there's much to be gained from sharing code here.<o:p class=""></o:p></span></div></div></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">In the end, its main job is to wrap an OutputDestination (low-level abstraction) in an Output (high-level abstraction). Output does a bunch of work for OutputDestination, such as manage the intermediate content buffer.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Probably it's better to have the OutputBackend return an Output directly (and get rid of the OutputManager).<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">(At one point OutputManager was managing multiple backends directly and was involved in the store operation(s); but since I factored that logic out to MirroringOutputBackend and OutputDestination it probably doesn't need to exist.)<o:p class=""></o:p></span></div></div><div class=""><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></p><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Any other major concerns / suggestions?<o:p class=""></o:p></span></div></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Thread-safety of the core plug-in interface is something that would be nice to explicitly address, as this has been a pain-point with vfs::FileSystem.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">It's tempting to say "not threadsafe, you should lock", but this results in throwing an unnecessary global lock around all FS accesses in multithreaded programs, in the common case that the real FS is being used.<o:p class=""></o:p></span></div></div></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Right, I hit multi-threading limitations myself when prototyping a follow-up patch (didn't get around to posting it until this AM):<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD95628&data=04%7C01%7Cchristudasan.devadasan%40amd.com%7C96736b89f9da4e9af05b08d8d73bd23d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637495999244989614%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NCauVgpaeceoz591JmHZo73rX3YcMmY1h5lM1VKml6I%3D&reserved=0" target="_blank" style="color: blue; text-decoration: underline;" class="">https://reviews.llvm.org/D95628</a><o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">My intuition is:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Thread-safe:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- OutputBackend::createDestination<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Concurrently touching more than one Output/OutputDestination<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Thread-unsafe:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Using a single Output/OutputDestination concurrently<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">This all seems cheap and easy to maintain because of the limited interface. The problem I hit in the above patch is that for the InMemoryOutputBackend you also need any readers of the InMemoryFileSystem to be thread-safe.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Relatedly, <a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD95583&data=04%7C01%7Cchristudasan.devadasan%40amd.com%7C96736b89f9da4e9af05b08d8d73bd23d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637495999244999606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WY9vUEtX5eK5kgoxvrGeXwn3IMxHFviabVk5nkq%2B0VQ%3D&reserved=0" target="_blank" style="color: blue; text-decoration: underline;" class="">https://reviews.llvm.org/D95583</a> (a prep patch for the above) allows the llvm::LockManager to be skipped. This is not really about outputs — it's inter-process coordination to avoid doing redundant work in competing Clang command-line invocations (at one point it was needed for correctness, but the main benefit now is to avoid taxing the on-disk filesystem) — but it does touch on the idea of exclusive write access.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Relatedly, working-directory/relative-path handling should be considered.<o:p class=""></o:p></span></div></div></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Yeah, you're probably right. Any specific thoughts on what to do here? It seems like llvm::vfs::FileSystem gets them pretty wrong for Windows; see (e.g.) the discussion at the end of <a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD70701&data=04%7C01%7Cchristudasan.devadasan%40amd.com%7C96736b89f9da4e9af05b08d8d73bd23d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637495999244999606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aVFmityBcNK1d0dmM1FZuUGgUzBafnLT%2FjpLk6%2BPizg%3D&reserved=0" target="_blank" style="color: blue; text-decoration: underline;" class="">https://reviews.llvm.org/D70701</a>.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Even for POSIX, working directories could complicate concurrency guarantees. A simple solution is to not have an API for <i class="">changing</i> working directories, and instead model that by creating a proxy backend (ChangeDirectoryOutputBackend) that prepends the (new) working directory to new outputs; since each backend has an immutable view of the CWD concurrent access should be fine.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Two other thoughts related to paths:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">1. I wonder if this abstraction treats the "path" as too central a property of the output. Can this evolve to allow a compiler to build a directory structure bottom-up without having to know the destination <i class="">a priori</i>? (E.g., an inner layer makes a blob, a middle layer makes a tree out of a few of those, and an outer layer decides where to put the tree.)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">I think it can. One approach is to use proxy backends:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Inner layer writes to '-' / stdout. (Why not pass a pre-constructed Output/raw_pwrite_stream? See note below.)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Middle layer passes the instances of the inner layer a proxy backend that maps stdout to the various blob names. (E.g., `/name1` and `/name2`.)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Outer layer passes the middle layer a proxy backend that "does the right thing" with the tree. (E.g., writes to `/Users/dexonsmith/name{1,2}`.)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">=> If writing on-disk, "the right thing" is to prepend the correct output directory for the tree and pass each file to a regular OnDiskOutputBackend.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">=> If writing to (e.g.) Git's CAS, "the right thing" is to call git-hash-object on Output::close and track the name-to-hash mapping as outputs come in, and then call "git-mktree" when the middle layer is "done" (maybe a callback in the backend-passed-to-the-middle-layer's destructor).<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">(IOW, a refactoring where instead of passing absolute paths / directories / filenames down through all the layers, proxy output backends build up the path/destination piece-by-piece.)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">I think it's doable with the abstraction as-proposed. But let me know if anyone has concerns. For example:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Is `Output::getPath()` an abstraction leak?<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Should we have a `createOutput` that doesn't take a path?<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- ...<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Why not pass a pre-constructed Output/raw_pwrite_stream to the inner layer?<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- The inner layer needs an output backend if it (sometimes) dumps "side" files (such as AST record layouts into ".ast-dump" or textual IR into ".ll"). This avoids needing to know the on-disk file path ("/path/to/output" => "/path/to/output.ll"), or to even know whether there's a disk.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">2. How should we virtualize stdout / stderr?<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- "'-' means stdout" is probably good enough since LLVM makes that assumption all over. Unless someone disagrees?<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- I'm not sure what to do with stderr. No one ever "closes" this stream.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Are there other outputs that don't have path names?<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">3. Do we need to virtualize llvm::sys::fs::create_directories?<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- If so, why?<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">(And a question/concern about the relationship between input and output virtualization, elaborated at the bottom)<o:p class=""></o:p></span></div></div></div></div></blockquote><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></p><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Why doesn't this inherit from llvm::vfs::FileSystem?</span></b><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""></o:p></span></div></div></div></blockquote><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Separating the input and output abstractions seems a bit cleaner. It's easy enough to join them, when useful: e.g., write to an `InMemoryFileSystem` (via an `InMemoryOutputBackend`) and install this same FS in the `FileManager` (maybe indirectly via an `OverlayFileSystem`).<o:p class=""></o:p></span></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">I agree with separating the interfaces. In hosted environments your input VFS is often read-only and outputs go somewhere else. <o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">But I wonder, is there an implicit assumption that data written to OutputManager is readable via the (purportedly independent) vfs::FileSystem? This seems like a helpful assumption for module caching, but is extremely constraining and eliminates many of the simplest and most interesting possibilities.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div></div></div></blockquote><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">If you're going to require the FileSystem and OutputBackend to be linked, then I think they *should* be the same object.<o:p class=""></o:p></span></div></div></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">No, I don't think that should be a requirement / expectation. It's a specific requirement for Clang's implicitly built modules, and I think Clang should be responsible for hooking them together when necessary.<o:p class=""></o:p></span></div></div><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></p><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">But if it's mostly module caching that requires that, then it seems simpler and less invasive to virtualize module caching directly (put(module, key) + get(key)) rather than file access.<o:p class=""></o:p></span></div></div></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Agreed, explicitly virtualizing module caching might be a good thing to do. Either way this is Clang's job to coordinate; I just think the output manager should efficiently support mirroring outputs to an additional/custom backend that Clang installs.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Note: implicit modules doesn't currently rely on reading the modules it has just built from disk. It uses InMemoryModuleCache to avoid having to read anything it has written to disk and to ensure consistency between CompilerInstances across an implicit build. It's pretty awkward though.<o:p class=""></o:p></span></div></div></div></div><div class=""><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></p><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">On 2021 Jan 28, at 03:19, Sam McCall <<a href="mailto:sammccall@google.com" target="_blank" style="color: blue; text-decoration: underline;" class="">sammccall@google.com</a>> wrote:<o:p class=""></o:p></span></div></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div><div class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Really glad to see this work, virtualizing module cache is something we've wanted to experiment with for tooling, but never got to. I want to get into the patches in more detail, but some high-level thoughts...<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">On Wed, Jan 27, 2021 at 6:23 AM Duncan P. N. Exon Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" style="color: blue; text-decoration: underline;" class="">cfe-dev@lists.llvm.org</a>> wrote:<o:p class=""></o:p></span></div></div><div class=""><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">TL;DR</span></b><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">: Let's virtualize compiler outputs in Clang. These patches would get us started:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- <a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD95501&data=04%7C01%7Cchristudasan.devadasan%40amd.com%7C96736b89f9da4e9af05b08d8d73bd23d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637495999245009605%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qNqDpPMaYIOUkNp4w2tz5RsbVnVX0bnMQLjPE7YkglE%3D&reserved=0" target="_blank" style="color: blue; text-decoration: underline;" class="">https://reviews.llvm.org/D95501</a> Add llvm::vfs::OutputManager<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- <a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD95502&data=04%7C01%7Cchristudasan.devadasan%40amd.com%7C96736b89f9da4e9af05b08d8d73bd23d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637495999245019597%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Rj%2FdYtAp%2Fy%2Fpa8ijPc4Cj08DDVnv91o2Vvkm6S%2FJJNk%3D&reserved=0" target="_blank" style="color: blue; text-decoration: underline;" class="">https://reviews.llvm.org/D95502</a> Initial adoption of llvm::vfs::OutputManager in Clang.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Questions for the reader</span></b><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Should we virtualize compiler outputs in Clang? (Hint: <i class="">yes</i>.)<o:p class=""></o:p></span></div></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Definitely agree.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""> <o:p class=""></o:p></span></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Does this support belong in LLVM? (I think it does, so that non-Clang tools can easily reuse it.)<o:p class=""></o:p></span></div></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Ideally, the core abstraction (path -> pwrite_stream) certainly belongs in LLVM, as well as the most common implementations of it.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Based on experience with VirtualFileSystem, I'd like this interface to be as narrow as possible to make it feasible to implement/wrap correctly, and to reason about how the wider system interacts with it.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">This roughly corresponds to OutputBackend + OutputDestination in the patch, except:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""> - the OutputConfig seems like it belongs to particular backends, not the overall backend abstraction<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""> - OutputDestination has a lot of stuff in it, I'll need to dig further into the patch to try to understand why<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">As for OutputManager itself, I think this belongs in clang, if it's needed. Its main job seems to be to store a set of default options and manage the lifecycle of backends, and it's not obvious that those sorts of concerns will generalize across tools or that there's much to be gained from sharing code here.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""> <o:p class=""></o:p></span></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Is `llvm::vfs::` a reasonable namespace? (If not, suggestions? I think `llvm::` itself is too broad.)<o:p class=""></o:p></span></div></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">llvm::vfs:: is definitely the right namespace for the core writing stuff IMO.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">If more ancillary bits (parts some but not all tools might use) need to go in llvm, llvm:: seems to be the best namespace we have (like e.g. SourceMgr) but maybe we should add a new one. But as mentioned, I'd prefer those to live in clang:: at least for now.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""> <o:p class=""></o:p></span></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Do you have a use case that this won't address well?<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Should that be fixed in the initial patch, or could this be evolved in-tree to address that?<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Any other major concerns / suggestions?<o:p class=""></o:p></span></div></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Thread-safety of the core plug-in interface is something that would be nice to explicitly address, as this has been a pain-point with vfs::FileSystem.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">It's tempting to say "not threadsafe, you should lock", but this results in throwing an unnecessary global lock around all FS accesses in multithreaded programs, in the common case that the real FS is being used.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Relatedly, working-directory/relative-path handling should be considered.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">(And a question/concern about the relationship between input and output virtualization, elaborated at the bottom)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""> <o:p class=""></o:p></span></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- If you think the above patches should be split up for initial review / commit, how?<o:p class=""></o:p></span></div></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Obviously my favorite would be to see a minimal core writable VFS interface extracted and land that first. What's built on top of it is less critical, and I'm not concerned about it landing in larger chunks.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""> <o:p class=""></o:p></span></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">(Other feedback welcome too!)<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Longer version</span></b><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">There are a number of use cases for capturing compiler outputs, which I'm hoping this proposal is a step toward addressing.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Tooling wants to capture outputs directly, without going through the filesystem.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Sometimes, tertiary outputs can be ignored, or still need to be written to disk.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- clang-scan-deps is using a form of stripped down "implicit" modules to determine which modules need to be built explicitly. It doesn't really want to be using the on-disk module cache—in-memory would be better.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- clang's ModuleManager manually maintains an in-memory modules cache for implicit modules. This involves copying the PCM outputs into memory. It'd be better for these modules to be file-backed, instead of copies of the stream.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">The patch has a bunch of details written / tested (<a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD95501&data=04%7C01%7Cchristudasan.devadasan%40amd.com%7C96736b89f9da4e9af05b08d8d73bd23d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637495999245019597%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KHnCUQUVkrueTPzGnuUdSsy%2FtoK%2Bm%2Fsx2EygUa434iw%3D&reserved=0" target="_blank" style="color: blue; text-decoration: underline;" class="">https://reviews.llvm.org/D95501</a>). Here are the high-level structures in the design:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- OutputManager—a shared manager for creating outputs without knowing about the storage.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- OutputConfig—configuration set on the OutputManager that can be (partially) overridden for specific outputs.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- Output—opaque object with a raw_pwrite_stream, output path, and `erase`/`close` functionality. Internally, it has a linked list of output destinations.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- OutputBackend—abstract interface installed in an OutputManager to create the "guts" of an output. While an OutputManager only has one installed, these can be layered / forked / mirrored.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- OutputDestination—abstract interface paired with an OutputBackend, whose lifetime is managed by an Output.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- ContentBuffer—actual content to allow efficient use of data by multiple backends. For example, the installed backend is a mirror between an on-disk and in-memory backend, the in-memory backend will either get the content moved directly into an llvm::MemoryBuffer, or a just-written mmap'ed file.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">The patch includes a few backends:<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">- NullOutputBackend, for ignoring all backends.<br class="">- OnDiskOutputBackend, for writing to disk (the default), initially based on the logic in `clang::CompilerInstance`.<br class="">- InMemoryOutputBackend, for writing to an `InMemoryFileSystem`.<br class="">- MirroringOutputBackend, for writing to multiple backends. OutputDestination's API is designed around supporting this.<br class="">- FilteringOutputBackend, for filtering which outputs get written to the underlying backend.<br class=""><br class=""><b class="">Why doesn't this inherit from llvm::vfs::FileSystem?</b><br class="">Separating the input and output abstractions seems a bit cleaner. It's easy enough to join them, when useful: e.g., write to an `InMemoryFileSystem` (via an `InMemoryOutputBackend`) and install this same FS in the `FileManager` (maybe indirectly via an `OverlayFileSystem`).<o:p class=""></o:p></span></div></div></blockquote><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">I agree with separating the interfaces. In hosted environments your input VFS is often read-only and outputs go somewhere else. <o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">But I wonder, is there an implicit assumption that data written to OutputManager is readable via the (purportedly independent) vfs::FileSystem? This seems like a helpful assumption for module caching, but is extremely constraining and eliminates many of the simplest and most interesting possibilities.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">If you're going to require the FileSystem and OutputBackend to be linked, then I think they *should* be the same object.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">But if it's mostly module caching that requires that, then it seems simpler and less invasive to virtualize module caching directly (put(module, key) + get(key)) rather than file access.<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;" class=""><div class=""><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Other work in the area</span></b><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">See also: <a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD78058&data=04%7C01%7Cchristudasan.devadasan%40amd.com%7C96736b89f9da4e9af05b08d8d73bd23d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637495999245029594%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qNhIbR5nDC8i2rfmKhNu2%2FyFjkth%2FA93NSC3lSoQ4Do%3D&reserved=0" target="_blank" style="color: blue; text-decoration: underline;" class="">https://reviews.llvm.org/D78058</a> (thanks to Marc Rasi for posting that patch, and to Sam McCall for some feedback on an earlier version of this proposal).<br class=""><br class="">Thanks for reading!<span class="Apple-converted-space"> </span><o:p class=""></o:p></span></div><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">Duncan<o:p class=""></o:p></span></div></div></div></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" style="color: blue; text-decoration: underline;" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-dev&data=04%7C01%7Cchristudasan.devadasan%40amd.com%7C96736b89f9da4e9af05b08d8d73bd23d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637495999245039588%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lAUN7ZPq0CUV2Ruy3bS185aNzG5s8CJyIWNRiOQAmBw%3D&reserved=0" target="_blank" style="color: blue; text-decoration: underline;" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><o:p class=""></o:p></span></div></blockquote></div></div></div></blockquote></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" style="color: blue; text-decoration: underline;" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=04%7C01%7Cchristudasan.devadasan%40amd.com%7C96736b89f9da4e9af05b08d8d73bd23d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637495999245039588%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gAN%2FpmMTyJ519JtTrsq%2BFXUvaH4xcX9wGp8iVeLN9rA%3D&reserved=0" target="_blank" style="color: blue; text-decoration: underline;" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p class=""></o:p></span></div></div></blockquote></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><o:p class=""> </o:p></span></div></div></div></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""></span><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" style="color: blue; text-decoration: underline;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">llvm-dev@lists.llvm.org</span></a><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class=""><br class=""></span><a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=04%7C01%7Cchristudasan.devadasan%40amd.com%7C96736b89f9da4e9af05b08d8d73bd23d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637495999245049587%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=04reiDV%2FP9Kn1GimtNvT015g5Lah%2F3cM3vg%2BzVaVqeY%3D&reserved=0" target="_blank" style="color: blue; text-decoration: underline;" class=""><span style="font-size: 10.5pt; font-family: Helvetica, sans-serif;" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</span></a></div></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote></div><br class=""></body></html>