[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: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.


>> 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/53f7989a/attachment.html>