Sent from my iPhone
> On Aug 14, 2014, at 19:52, Nico Weber <[email protected]> wrote:
>
>> On Thu, Aug 14, 2014 at 4:40 PM, Rafael Avila de Espindola
>> <[email protected]> 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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
