[PATCH] D11026: [ARM] Define subtarget feature "dont-use-movt" to disallow emitting movt/movw pairs

Akira Hatanaka ahatanak at gmail.com
Tue Jul 14 22:33:26 PDT 2015


OK, I'll go with no-movt instead of dont-use-movt.

On Tue, Jul 14, 2015 at 10:16 PM, Eric Christopher <echristo at gmail.com>
wrote:

> They do. I was asking for a positive feature rather than a negative one
> just to keep a decent lattice of adding features to a function - that said,
> I don't think this will get in the way too much. Go ahead and pick the name
> that sounds least bad and go for it :)
>
> -eric
>
> On Thu, Jul 9, 2015 at 11:48 AM Akira Hatanaka <ahatanak at gmail.com> wrote:
>
>> I think those names look better than "dont-use-movt".
>>
>>
>> On Thu, Jul 9, 2015 at 8:53 AM, Duncan P. N. Exon Smith <
>> dexonsmith at apple.com> wrote:
>>
>>>
>>> > On 2015-Jul-08, at 16:16, Akira Hatanaka <ahatanak at gmail.com> wrote:
>>> >
>>> >
>>> >> On 2015-Jul-08, at 13:52, Eric Christopher <echristo at gmail.com>
>>> wrote:
>>> >>
>>> >> Let's have the feature be a positive feature that just happens to be
>>> on by default in a lot of places. +/-dont-use-movt seems weird.
>>> >>
>>> > Do you mean I should replace ARMSubtarget::DontUseMovt with
>>> ARMSubtarget::UseMovt which is true by default? That should work.
>>> >
>>> > Or do you mean we should use FeatureUseMovt :
>>> SubtargetFeature<"use-movt"> instead of
>>> FeatureDontUseMovt<"dont-use-movt">? If I understand correctly how
>>> subtarget features work, I think that would require clang (and other
>>> front-ends) to add feature "+use-movt" whenever we want to allow emitting
>>> movt/movw pairs as opposed to adding "+dont-use-movt" only when we want to
>>> disallow doing so. Assuming you would want to allow movt/movw pairs in the
>>> common case, wouldn't it be better to use a negative feature?
>>>
>>> Maybe there's another negative name that isn't as strange.  Something
>>> like "avoid-movt" or "no-movt"?
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150714/5208c723/attachment.html>


More information about the llvm-commits mailing list