Soumya AR <soum...@nvidia.com> writes: >> On 18 Feb 2025, at 2:27 PM, Kyrylo Tkachov <ktkac...@nvidia.com> wrote: >> >> >> >>> On 18 Feb 2025, at 09:48, Kyrylo Tkachov <ktkac...@nvidia.com> wrote: >>> >>> >>> >>>> On 18 Feb 2025, at 09:41, Richard Sandiford <richard.sandif...@arm.com> >>>> wrote: >>>> >>>> Kyrylo Tkachov <ktkac...@nvidia.com> writes: >>>>> Hi Soumya >>>>> >>>>>> On 18 Feb 2025, at 09:12, Soumya AR <soum...@nvidia.com> wrote: >>>>>> >>>>>> generic_armv8_a.h defines generic_armv8_a_prefetch_tune but still uses >>>>>> generic_prefetch_tune in generic_armv8_a_tunings. >>>>>> >>>>>> This patch updates the pointer to generic_armv8_a_prefetch_tune. >>>>>> >>>>>> This patch was bootstrapped and regtested on aarch64-linux-gnu, no >>>>>> regression. >>>>>> >>>>>> Ok for GCC 15 now? >>>>> >>>>> Yes, this looks like a simple oversight. >>>>> Ok to push to master. >>>> >>>> I suppose the alternative would be to remove generic_armv8_a_prefetch_tune, >>>> since it's (deliberately) identical to generic_prefetch_tune. >>> >>> Looks like we have one prefetch_tune structure for each of the generic >>> tunings (generic, generic_armv8_a, generic_armv9_a). >>> For the sake of symmetry it feels a bit better to have them independently >>> tunable. >>> But as the effects are the same, it may be better to remove it in the >>> interest of less code. >>> >> >> I see Soumya has already pushed her patch. I’m okay with either approach >> tbh, but if Richard prefers we can remove generic_armv8_a_prefetch_tune in a >> separate commit. > > Yeah, missed Richard’s mail. > > Let me know which is preferable, thanks.
No, it's fine as is. My comment was just a suggestion. Thanks, Richard
