[PATCH] [AArch64] Refactor AArch64NamedImmMapper to become dependent on subtarget features.

[Eric Christopher]

A better question might be:

Why are all of these classes copying the feature sets and using them with
their own API?

-eric

On Thu, Mar 26, 2015 at 2:39 PM James Molloy <james at jamesmolloy.co.uk>
wrote:

> Hi Eric,
>
> Thanks for the clarification. I'm afraid I don't fully understand what
> you're saying though, so perhaps you could clarify further?
>
> The mapper classes map between a textual register/prefetch
> operation/barrier name and its binary equivalent. Whether this succeeds is
> sometimes dependent on a subtarget feature being available. My reading of
> this patch (and the code in situ) is that the mapper classes take a
> subtarget feature set and query it. The input comes transitively from
> ComputeAvailableFeatures(), so I'm afraid I don't understand what about
> this is "reimplementing".
>
> Sorry,
>
> James
>
> On Thu, 26 Mar 2015 at 19:53 Eric Christopher <echristo at gmail.com> wrote:
>
>> Why are you effectively reimplementing the feature sets for this class?
>>
>> -eric
>>
>>
>> REPOSITORY
>>   rL LLVM
>>
>> http://reviews.llvm.org/D8496
>>
>> EMAIL PREFERENCES
>>   http://reviews.llvm.org/settings/panel/emailpreferences/
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150326/dee9b2da/attachment.html>