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

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

[Palmer Dabbelt]

On Wed, 22 Nov 2023 14:27:50 PST (-0800), jeffreyalaw@gmail.com wrote:
> ...

[Trimming everything else, as this is a big change.  I'm also making it 
a new subject/thread, so folks can see.]

> More generally, I think I need to soften my prior statement about
> deferring this to gcc-15.  This code was submitted in time for the
> gcc-14 deadline, so it should be evaluated just like we do anything else
> that makes the deadline.  There are various criteria we use to evaluate
> if something should get integrated and we should just work through this
> series like we always do and not treat it specially in any way.

We talked about this some in the pachwork meeting today.  There's a lot 
of moving parts here, so here's my best bet at summarizing 

It seems like folks broadly agree: I think the only reason everyone was 
so quick to defer to 15 was because we though the Vrull guys even want 
to, but sounds like there's some interest in getting this into 14.  
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 actually find some time to sit down and do the code review.  
  That'll be a chunk of work and time is tight since most of us are 
  focusing on V-1.0, but hopefully we've got time to fit things in.
* There's some options for testing without hardware: QEMU dropped 
  support for V-0.7.1 a while ago, but there's a patch set that's not 
  yet on the lists to bring that back.

So I think unless anyone's opposed, we can at least start looking into 
getting this into GCC-14 -- there's obviously still a ton of review work 
to do and we might find something problematic, but we won't know until 
we actually sit down and do the reviews.

---

Then for my opinions:

The only policy worry I have is the support lifecycle: IMO merging 
something we're going to quickly deprecate is going to lead to headaches 
for users, so we should only merge this if we're going to plan on 
supporting it for the life of the hardware.  That's always hard to 
define, but we talked through the option of pushing this onto the users: 
we'd require test results published for every GCC release, and if no 
reasonably cleas test results are published then we'll assume the HW is 
defunct and support for it can be deprecated.  That's sort of patterned 
on how glibc documents deprecating ports.

IIRC we didn't really end up with any deprecation policy when merging 
the other vendor support, so I'd argue we should just make that the 
general plan for supporting vendor extensions.  It pushes a little more 
work to the vendors/users than we have before, but I think it's a good 
balance.  It's also a pretty easy policy for vendors to understand: if 
they want their custom stuff supported, they need to demonstrate it 
works. 

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

[Philipp Tomsich]

On Tue, 28 Nov 2023 at 20:31, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Wed, 22 Nov 2023 14:27:50 PST (-0800), jeffreyalaw@gmail.com wrote:
> > ...
>
> [Trimming everything else, as this is a big change.  I'm also making it
> a new subject/thread, so folks can see.]
>
> > More generally, I think I need to soften my prior statement about
> > deferring this to gcc-15.  This code was submitted in time for the
> > gcc-14 deadline, so it should be evaluated just like we do anything else
> > that makes the deadline.  There are various criteria we use to evaluate
> > if something should get integrated and we should just work through this
> > series like we always do and not treat it specially in any way.
>
> We talked about this some in the pachwork meeting today.  There's a lot
> of moving parts here, so here's my best bet at summarizing
>
> It seems like folks broadly agree: I think the only reason everyone was
> so quick to defer to 15 was because we though the Vrull guys even want
> to, but sounds like there's some interest in getting this into 14.

Thank you for the follow-up on this, as I had the original
conversation with Jeff in passing.
We (and the Alibaba folks and the BeagleV-AHEAD community) would
prefer to get this into 14.

> 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.

Philipp.

> * We actually find some time to sit down and do the code review.
>   That'll be a chunk of work and time is tight since most of us are
>   focusing on V-1.0, but hopefully we've got time to fit things in.
> * There's some options for testing without hardware: QEMU dropped
>   support for V-0.7.1 a while ago, but there's a patch set that's not
>   yet on the lists to bring that back.
>
> So I think unless anyone's opposed, we can at least start looking into
> getting this into GCC-14 -- there's obviously still a ton of review work
> to do and we might find something problematic, but we won't know until
> we actually sit down and do the reviews.
>
> ---
>
> Then for my opinions:
>
> The only policy worry I have is the support lifecycle: IMO merging
> something we're going to quickly deprecate is going to lead to headaches
> for users, so we should only merge this if we're going to plan on
> supporting it for the life of the hardware.  That's always hard to
> define, but we talked through the option of pushing this onto the users:
> we'd require test results published for every GCC release, and if no
> reasonably cleas test results are published then we'll assume the HW is
> defunct and support for it can be deprecated.  That's sort of patterned
> on how glibc documents deprecating ports.
>
> IIRC we didn't really end up with any deprecation policy when merging
> the other vendor support, so I'd argue we should just make that the
> general plan for supporting vendor extensions.  It pushes a little more
> work to the vendors/users than we have before, but I think it's a good
> balance.  It's also a pretty easy policy for vendors to understand: if
> they want their custom stuff supported, they need to demonstrate it
> works.

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

[Jeff Law]

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.

Jeff

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

[Jason Kridner]

[-- 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