Re: T-Head Vector for GCC-14? (was Re: RISC-V: Support XTheadVector extensions)
On Tue, Nov 28, 2023 at 5:21 PM Jeff Law 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
Re: T-Head Vector for GCC-14? (was Re: RISC-V: Support XTheadVector extensions)
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)
On Tue, 28 Nov 2023 at 20:31, Palmer Dabbelt wrote: > > On Wed, 22 Nov 2023 14:27:50 PST (-0800), jeffreya...@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.
T-Head Vector for GCC-14? (was Re: RISC-V: Support XTheadVector extensions)
On Wed, 22 Nov 2023 14:27:50 PST (-0800), jeffreya...@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.
