[llvm] r273148 - [AARCH64] Add support for Broadcom Vulcan

Eric Christopher via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 20 17:11:05 PDT 2016


Yep. That's exactly what needs to be done - hence me asking why the
subtarget cpus were seen to be a good idea.

-eric

On Mon, Jun 20, 2016 at 5:09 PM Renato Golin <renato.golin at linaro.org>
wrote:

> Basically, https://llvm.org/bugs/show_bug.cgi?id=27992
> On 21 Jun 2016 1:00 a.m., "Eric Christopher" <echristo at gmail.com> wrote:
>
>>
>>
>> On Mon, Jun 20, 2016 at 3:34 PM Renato Golin <renato.golin at linaro.org>
>> wrote:
>>
>>> On 20 June 2016 at 23:25, Eric Christopher <echristo at gmail.com> wrote:
>>> > That said, one way I've seen these sorts of things being used is via
>>> > ST->isCPUX() for TTI and a few other things which is fairly valid. We
>>> might
>>> > need a better way of doing that, basically defining the name of the
>>> cpu as a
>>> > subtarget feature is a bit wonky really.
>>>
>>> We're moving things from isCPUX to hasFeature to get rid of long
>>> conditionals (isX || isY || isZ || ... ) and to make matters clear why
>>> is it that way.
>>>
>>> But that doesn't preclude us from getting rid of the feature name and
>>> its bad usage. We just want to keep the feature-based code gen, that's
>>> all.
>>>
>>> Btw, there are patches coming on ARM to replace isCPUX with target
>>> features from us in the next few days / weeks, so we may want to wait
>>> until that's done to refactor the SubtargetFeature list.
>>>
>>>
>> Seems reasonable. I'm curious which way you're going so if you wouldn't
>> mind adding me here I'd appreciate it.
>>
>> Thanks!
>>
>> -eric
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160621/09c39345/attachment.html>


More information about the llvm-commits mailing list