rfc and [patch]: Unify -mfpu and .fpu handling, let .fpu toggle features

[Rafael Avila de Espindola]

Sent from my iPhone

> On Aug 14, 2014, at 19:52, Nico Weber <thakis at chromium.org> wrote:
> 
>> On Thu, Aug 14, 2014 at 4:40 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote:
>> 
>> > 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.
>> >
>> > (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.)
>> 
>> 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?
> 
> 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?

Yes, I agree, they are both equally odd.

What is the size impact in libclang? It links with lib/Driver, no?

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 :-(

Cheers,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140814/322e5c0a/attachment.html>