<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br><br>Sent from my iPhone</div><div><br>On Aug 14, 2014, at 19:52, Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 14, 2014 at 4:40 PM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><br>
> One drawback is that the new ARMSubtargetCommon.cpp file is in the library ARMCodeGen, so clang's driver now depends on ARMCodeGen, which is a bit icky. I could make it a standalone target I suppose, but that standalone target's cpp file depends on the ARMCodeGen target's tablegen output, so that wouldn't be a huge win. And since the driver processes flags related to ARMCodeGen, the dependency doesn't seem _that_ icky to me.<br>
><br>
> (There are several places in the driver that say "FIXME: this is duplicating subtarget code", both for ARM and x86, this patch removes one of them.)<br>
<br>
</div>Does the driver need to process the -mfpu just to pass the results to -cc1 or is the information needed for something like deciding which libraries to link with? If just -cc1, maybe we could just pass down the raw option?</blockquote>
<div><br></div><div>It's possible, but translating flags into -target-option flags in the driver is pretty pervasive in the driver (63 "Features.push_back" calls in lib/Driver/Tools.cpp). So that'd be fairly different from the current code, and I'm not sure if Frontend depending on ARMCodeGen is much better than Driver depending on it?</div></div></div></div>
</blockquote><br><div>Yes, I agree, they are both equally odd.</div><div><br></div><div>What is the size impact in libclang? It links with lib/Driver, no?</div><div><br></div><div>Short of creating a small libTargetInfo for each target your approach is probably the best. We discussed doing something like it for solving the data layout duplication, but I never got around to implementing it :-(</div><div><br></div><div>Cheers,</div><div>Rafael</div></div></body></html>