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

[Akira Hatanaka]

On Tue, Jun 23, 2015 at 1:51 PM, Akira Hatanaka <ahatanak at gmail.com> wrote:

> On Tue, Jun 23, 2015 at 1:21 PM, Eric Christopher <echristo at gmail.com>
> wrote:
>
>>
>>
>> On Tue, Jun 23, 2015 at 12:03 PM Akira Hatanaka <ahatanak at gmail.com>
>> wrote:
>>
>>> On Mon, Jun 22, 2015 at 2:00 PM, Eric Christopher <echristo at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jun 22, 2015 at 1:49 PM Akira Hatanaka <ahatanak at gmail.com>
>>>> wrote:
>>>>
>>>>> In http://reviews.llvm.org/D10414#191915, @echristo wrote:
>>>>>
>>>>> > Another possibility is that this gets mapped as a normal command
>>>>> line option passed into cc1 and then it can just be a subtarget feature?
>>>>>
>>>>>
>>>>> Would it look something like this in the IR?
>>>>>
>>>>> "target-features"="+neon,+vfp3,arn-restrict-it=false"
>>>>>
>>>>
>>>> was thinking of more just:
>>>>
>>>> "target-features"="+neon,+vfp3,-restrict-it"
>>>>
>>>> Though if we're going for "restrict-it" blocks perhaps a better name
>>>> that works well with +/-?
>>>>
>>>> I've generally stayed away from turning command line options into
>>>> features, but in the case of something that appears to turn on actual code
>>>> generation features it seems like it might be reasonable.
>>>>
>>>>
>>> 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 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/42a330c4/attachment.html>