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

Eric Christopher via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 21 14:33:20 PDT 2016


No need to worry on your side. The vulcan stuff will be fixed up at the
same time as some of the rest. Renato, Tim, and I just need to come to
agreement on some of what needs to happen.

Thanks!

-eric

On Mon, Jun 20, 2016 at 11:28 PM Pankaj Gode <pankaj.gode at broadcom.com>
wrote:

> Hi Eric & Renato,
>
> Please let me know if I should take any action, in terms of correction or
> modification now or later.
>
> I also want to mention the obvious, that this is a base patch for enabling
> Vulcan support.
> In subsequent patches, there is a plan to add Vulcan scheduling model and
> tuning parameters.
>
> Thanks & Regards,
> Pankaj
>
>
> On Tue, Jun 21, 2016 at 5:53 AM, Eric Christopher <echristo at gmail.com>
> wrote:
>
>> Okay, sounds good!
>>
>> On Mon, Jun 20, 2016 at 5:23 PM Renato Golin <renato.golin at linaro.org>
>> wrote:
>>
>>> 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/bbf6d943/attachment.html>


More information about the llvm-commits mailing list