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

[Philipp Tomsich <philipp.tomsich@vrull.eu>]

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.