r188906 - Centralize the handling of -target-feature.

[Daniel Dunbar]

Hi Rafael,

Here is how I see it. There are two problems:

1. For consistency, it would be ideal if we set up the target machine state
the same when using the frontend or the assembler. We don't currently do
that for the assembler, we pass the options directly to the backend and
never even instantiate the frontend TargetInfo. If we did, and used its
handleTargetFeatures hook, then we could ensure the assembler and the
frontend behave the same.

2. The use of soft-abi as a target feature is a hack, and it might be good
for us to have a generic mechanism like TargetOption as you propose. This
seems like general goodness.

Fixing either one of these will resolve this particular issue, but fixing
both of them might make sense. Thoughts?

 - Daniel



On Mon, Oct 28, 2013 at 9:03 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> On 28 October 2013 23:28, Lang Hames <lhames at gmail.com> wrote:
> > Hi Rafael,
> >
> > I noticed that as a consequence of this patch, clang is issuing the
> > following warning when assembling for arm:
> >
> > "'+soft-float-abi' is not a recognized feature for this target (ignoring
> > feature)"
> >
> > You can reproduce this (at least on Darwin, and I expect on Linux too) by
> > creating an empty foo.s file and running:
> >
> > clang -arch armv7 -c foo.s
> >
> > It looks like the cause of the warning is that both Clang::ConstructJob
> and
> > ClangAs::ConstructJob are both calling getARMTargetFeatures (indirectly
> via
> > getTargetFeatures), and getARMTargetFeatures always adds the
> abi-appropriate
> > flag, even when the driver was being invoked as an assembler.
> >
> > I'm not very familiar with the driver code, so I didn't want to jump in
> and
> > undo any of the useful parts of your refactor to fix this.
> >
> > Do you have any thoughts on the right way to omit this flag when
> assembling?
>
> Good question. These are odd "feature, but not really". It looks like
> the driver passes them as features because that is all that TargetInfo
> in "clang -cc1" will see. Some options would be
>
> * Don't pass this information as features. Call them TargetOptions or
> something like that and add a  virtual bool handleTargetOption.
> * Make them real features (attached patch).
> * Pass a flag to getARMTargetFeatures so that it knows the target
> features are being collected for the assembler.
>
> Daniel, you added this back in r91755 along with the "this is a hack"
> FIXME. What was the direction you wanted this to take?
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131111/f73de396/attachment.html>