<p dir="ltr">Yep. Here too. </p>
<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 7, 2017, 9:13 AM Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, "all" is "all configured" I think throughout this discussion. Sorry for that confusion.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 7, 2017 at 6:09 PM Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_1037289956696607652m_-4758801597557837024WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Could you guys clarify one thing for me? It sounds like the idea is that the current model of configuring the selection of targets would go away, to be replaced
by an all-or-native-only switch. Sometimes I like to configure X86+ARM because that reduces rebuild time and still gets me the vast majority of debug-info tests.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Or maybe you're using "all" as a shorthand for "all configured targets" which would be just fine.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr<u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_1037289956696607652_m_-4758801597557837024__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>Chandler Carruth via llvm-dev<br>
<b>Sent:</b> Wednesday, December 06, 2017 5:14 PM<br>
<b>To:</b> Eric Christopher<br>
<b>Cc:</b> llvm-dev; Richard Smith<br>
<b>Subject:</b> Re: [llvm-dev] TargetSelect.h and layering<u></u><u></u></span></p>
</div>
</div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_1037289956696607652m_-4758801597557837024WordSection1"><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">FWIW, I think the end state we'll end up wanting is what you describe in your email: fine grained dependencies and something like <span style="color:#212121">libLLVM{AllTargets,NativeTarget}{AsmPrinters,AsmParsers,Descs,Disassemblers,Infos}</span><u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">I think the "Native" thing can be solved by having a CMake (and llvm-config) level alias that points to a specific single target library. Then I think you could actually build lib/Target/All/... directory tree
that provides the "all" libraries and links everything together.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">Last but not least, I think in this world we'd want each of the narrow, specific interfaces to be *inside* the individual target libraries rather than squeezed into a single header file.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121">But this is a lot of churn and work. So I'm not seeing a huge problem if it is ust too much churn and work and you make the header a textual header for now. I'd document this super clearly in the header and lift
it up a directory to live alongside our other textual headers like LinkAllPasses.h</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Dec 7, 2017 at 2:10 AM Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">My only alternate ideas are:<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">a) To heck with this only a single target thing.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">b) Autogenerate the entire file and library support as part of the build and have the various functions "defined" in the appropriate libraries.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I don't really think a) is feasible, and b) is a bit of a stretch too. :\<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-eric<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Dec 4, 2017 at 5:37 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Ping - any further/other thoughts from folks? I'm not /too/ fussed, but generally like the idea of lib layering being simple/clear/obvious, but understand these are sort of the degenerate/worst case.<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Tue, Nov 28, 2017 at 12:12 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal">On Tue, Nov 28, 2017 at 11:27 AM Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal">On Tue, Nov 28, 2017 at 11:23 AM, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
<div>
<p class="MsoNormal">Alternatively we can really say this header is a textual header - it's included generally only once in a whole program, the functions are called only once, etc. Though that does seem a little unfortunate on principle but not much practical
problem with it, I think. It'd be nice in theory to be able to depend on the right library, have that bring in the right dependencies, etc.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">As designed, TargetSelect.h doesn't fit neatly into the normal way of arranging libraries.<u></u><u></u></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><br>
Not sure about that - yeah, it's a bit of the degenerate case, for sure.<br>
<br>
But in a build system like Google's, where a lib has other lib dependencies (whereas in the LLVM CMake build it seems libs don't depend on other libs - so every executable has to explicitly list its transitive lib dependencies) it's pretty nice to have these
little libraries explicitly in the build graph - much like we have those synthetic library targets in the CMake rules, so it's easy to depend on the right/full things.<br>
<br>
(but because the CMake lib rules for LLVM don't actually describe lib dependencies, I think even 'fixing' this in upstream LLVM wouldn't make the dep situation better - the synthetic targets would just have to expand to the underlying libs + the wrapper/selector
lib as well)<br>
<u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<p class="MsoNormal">I'd mark it textual and leave it alone.<u></u><u></u></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><br>
Yeah, maybe... just makes me a bit sad to have inline functions that can't be trivially out-of-lined if/when desired, because they layering isn't fully/correctly represented in the build system. Modular codegen's been a good justification to flush out & fix
several of these tricksy layering violations in LLVM already.<br>
<u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Alternatively, we could make AllTargetsDescs and AllTargetsInfos and all the other synthetic libraries in CMake into real libaries and sink the bodies of these inline functions into each tiny little library. Doesn't seem quite worth it,
though.<u></u><u></u></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div></div></div></blockquote></div>
</blockquote></div>