r188906 - Centralize the handling of -target-feature.

[Lang Hames]

Hi Guys,

Any further thoughts on this? I'd keen to see it fixed one way or another -
getting that warning every time ARM is assembled is less than ideal.

If this is going to require some significant infrastructure changes, is
there a reasonable short-term fix that we can apply?

- Lang.



On Mon, Nov 11, 2013 at 12:04 PM, Daniel Dunbar <daniel at zuster.org> wrote:

> 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/20131118/577278b9/attachment.html>