r188906 - Centralize the handling of -target-feature.

[Rafael Espíndola]

Hi lang,

Sorry I missed your previous message. I will just avoid passing the
flag to cc1as for now and leave a FIXME on the lines Daniel Dunbar
suggested.

On 22 November 2013 19:31, Lang Hames <lhames at gmail.com> wrote:
> Hi Rafael,
>
> Are you likely to be able to make a proper fix for this soon? If not I think
> it should be reverted for now - it's still broken.
>
> Cheers,
> Lang.
>
>
> On Mon, Nov 18, 2013 at 4:02 PM, Lang Hames <lhames at gmail.com> wrote:
>>
>> 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
>>>
>>>
>>
>