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

[Renato Golin via llvm-commits]

Oh, right. Diana is going one by one, for every use of "is cpu x", and will
submit patches. I'm not sure of the sequence.

I remember trying to do something similar in the past but always getting
stuck with too many changes. I think her approach to pick lots of small
fights (code and bikeshedding) is probably more productive.

If you want to share the load, or discuss the overall approach, you better
coordinate / discuss that on the bug, as she can give you a better
overview.

We're finally doing some much needed refactoring in the arm and AArch64
back ends, so any additional pair of eyes (and hands) is welcome! :-)

Cheers,
Renato
On 21 Jun 2016 1:11 a.m., "Eric Christopher" <echristo at gmail.com> wrote:

> 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/309ea57d/attachment.html>