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

[Eric Christopher]

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?


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

-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/3ca2024a/attachment.html>