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? > 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. Right.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
