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

Nico Weber thakis at chromium.org
Thu Aug 14 16:52:57 PDT 2014

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?

> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140814/bdf0c810/attachment.html>

More information about the cfe-commits mailing list