[PATCH] Attach function attribute "arm-restrict-it" instead of passing arm-restrict-it as a backend-option

[Eric Christopher]

>
>
>>>>>
>>>> Since restrict-it is a tri-state, I think you'll have to define two new
>>>> subtarget features in ARM.td (see the attached patch). I'm not sure how
>>>> prefixing "restrict-it" by "-" is going to work.
>>>>
>>>
>>> I think default is a red herring here a bit. It's either on or off right
>>> now, we might have to bake in some back end knowledge in the front end
>>> about when to apply it, but it should still work out yes?
>>>
>>>
>> Yes, we'll have to know whether "restrict-it" or "no-restrict-it" was
>> passed on command line and whether v8 is supported.
>>
>>
> As per your suggestion, I added one feature in ARM.td and then fixed
> getARMTargetFeatures in lib/Driver/Tools.cpp to push feature "+restrict-it"
> to the feature list based on the subarch.
>
> It seems to me that we can add code-gen options to the IR as subtarget
> features in most cases, but it's not clear to me when to use function
> attributes and when to use subtarget features. Should we convert
> target-specific code-gen options into subtarget features whenever it is
> possible to do so, and  convert target-independent options into function
> attributes?
>
>
This is what I've been thinking at the moment. I think it cleans up quite a
bit of the interface mechanics etc. I've even added one more
target-independent one (soft-float) as a subtarget feature because that
seems to make the most sense. I think at least some of these are going to
be on a case by case basis, but this seems to make the most sense to me.

-eric


>
>>>> This approach can potentially create larger numbers of subtarget
>>>> objects as two subtarget objects have to be created If one function has
>>>> feature "restricted-it" and another has feature "no-restricted-it". If we
>>>> take the approach in my original patch, we need only one subtarget object.
>>>> Do you think that's going to be a problem?
>>>>
>>>>
>>> Irrespective of the above I'm not too worried about this. In general,
>>> people have a tendency to use the same command line options everywhere,
>>> especially for this sort of thing.
>>>
>>>
>> I would think so too.
>>
>> -eric
>>>
>>>
>>>> -eric
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> http://reviews.llvm.org/D10414
>>>>>>
>>>>>> EMAIL PREFERENCES
>>>>>>   http://reviews.llvm.org/settings/panel/emailpreferences/
>>>>>>
>>>>>>
>>>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150623/624f1517/attachment.html>