<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><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"> Would this help with the dependency? The front end at least would still have the dependency to find out which defines to produce I think.</blockquote>
</div><br></div><div class="gmail_extra">Right.</div></div>