<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 31, 2015 at 5:50 PM Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On 2015-Aug-31, at 12:21, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br>
> Yep. This is where I was going :)<br>
<br>
Glad I found consensus, but I want to double-check that this makes<br>
sense to add to the driver.  I didn't quite think through the<br>
implications myself.<br>
<br>
Since the driver doesn't know if there's any bitcode, or if LTO is<br>
going to be invoked, it seems like I'll have to change the noasserts<br>
driver to *always* pass the option to the linker just in case we are<br>
doing LTO.  Is this reasonable?<br>
<br>
Also, I realized that passing `-mllvm -disable-llvm-verifier` to ld64<br>
is redundant... so I'm thinking `-mllvm -disable-verify`.  Make<br>
sense?<br></blockquote><div><br></div><div>*sigh* Reasons to hate the driver interface again...</div><div><br></div><div>I guess this is ok. Could possibly add it to the existing terrible "enable this pass" interface on liblto as well. </div><div><br></div><div>I don't suppose ld64 could move to a model like we're talking about with lld that pcc is working on?</div><div><br></div><div>-eric</div><div> </div></div></div>