Re: T-Head Vector for GCC-14? (was Re: RISC-V: Support XTheadVector extensions)

[Jason Kridner <jkridner@beagleboard.org>]

[-- Attachment #1: Type: text/plain, Size: 3133 bytes --]

On Tue, Nov 28, 2023 at 5:21 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
>
> On 11/28/23 12:56, Philipp Tomsich wrote:
>
> >> That's obviously a risky thing to do given it was sent right at the end
> >> of the window, but it meets the rules.
> >>
> >> Folks in the call seemed generally amenable to at least trying for 14,
> >> so unless anyone's opposed on the lists it seems like the way to go.
> >> IIRC we ended up with the following TODO list:
> >>
> >> * Make sure this doesn't regress on the targets we already support.
> >>    From the sounds of things there's been test suite runs that look
fine,
> >>    so hopefully that's all manageable.  Christoph said he'd send
> >>    something out, we've had a bunch of test skew so there might be a
bit
> >>    lurking but it should be generally manageable.
> >> * We agree on some sort of support lifecycle.  There seemed to be
> >>    basically two proposals: merge for 14 with the aim of quickly
> >>    deperecating it (maybe even for 15), or merge for 14 with the aim of
> >>    keeping it until it ends up un-tested (ie, requiring test results
are
> >>    published for every release).
> >
> > We expect real-world users, including the BeagleV-AHEAD community, to
> > need support for the foreseeable future.
> > Keeping it until it ends up untested (and test cases are reasonably
> > clean) sounds like a good threshold to ensure the integrity of the
> > codebase while giving this a clear path to stay in for its useful
> > life.
> I can live with it being in the tree as long as it's maintained
> (measured by ongoing testing with reasonable results).
>
> I'd proposed that it could end up deprecated quickly, but that was based
> on the assumption that once V1.0 compliant hardware was widely available
> that we'd see less and less interest in the thead extensions.
>

At BeagleBoard.org, we focus on long-term support and availability.
Long-term support is a key for us engaging with education, both
institutional and continuing, and industrial automation. Getting this into
mainline such that we can develop solutions that integrate with mainline
Linux distributions is key for us to enable broader RISC-V adoption. If it
is deprecated at some point, that won't be terrible as long as we are able
to get to a good snapshot where integration with the rest of the open
source developer community has reasonably happened.

The good news is it *will* get tested. We have confidence in that side of
things. We have a great community that will engage the compiler and
identify regressions.

My expectation is that the Alibaba folks really know the C910 CPU core and
will help us get things right. I'll be here to help escalate issues to them
if they become unresponsive to the list. Others involved in the
BeagleBoard.org project will help make sure I know when I need to escalate
such issues.

Let me know if there's anything I can do to encourage this being merged and
worrying about deprecation later.

--
https://beagleboard.org/about/jkridner - a 501c3 non-profit educating
around open hardware computing