Lehua Ding <lehua.d...@rivai.ai> writes:
> Hi Sam, > > On 2023/11/18 16:06, Sam James wrote: >> Lehua Ding <lehua.d...@rivai.ai> writes: >> >>> Hi Vladimir, >>> >>> On 2023/11/17 22:05, Vladimir Makarov wrote: >>>> On 11/16/23 21:06, Lehua Ding wrote: >>>>> Hi Vladimir, >>>>> >>>>> Thank you so much for your review. Based on your comments, I feel >>>>> like there are a lot of issues, especially the long compile time >>>>> issue. So I'm going to reorganize and refactor the patches so that >>>>> as many of them as possible can be reviewed separately. this way >>>>> there will be fewer patches to support subreg in the end. I plan to >>>>> split it into four separate patches like bellow. What do you think? >>>>> >>>> I can wait for the new version patches. The only issue is stage1 deadline. >>>> In my opinion, I'd recommend to work on the patches more and start >>>> their submission right before GCC-14 release (somewhere in April). >>> >>> Quite agree, I'll rewrite the patches a bit better before resend new >>> version patchs, stage 1 is definitely too late. When you say before >>> GCC-14 release do you mean at GCC 14 stage 3? Is it possible to commit >>> such changes at stage 3? I was thinking that if I miss GCC 14 stage 1 >>> I should have to wait until GCC 15 stage 1. >> I took it to mean "submit it during GCC 14 stage 3 for merging >> during >> GCC 15 stage 1", as the idea would be that if you're basing it on the >> state of the tree & doing further/final testing on GCC 14 stage 3, >> the tree should be in a stable state by then with only regression fixes >> going in, rather than other changes which might disrupt your testing. >> This means you are not constantly rebasing and getting new test >> failures >> possibly due to changes other than yours. It also means lots of time to >> review and fix any problems with less pressure. > > Oh, looks like I misunderstood. Thanks for the correction. > >>> >>>> You need a lot of testing for the patches: major targets (x86-64, >>>> aarhc64, ppc64), some big endian targets, a 32-bit targets. Knowing >>>> how even small changes in RA can affect many targets, e.g. GCC >>>> testsuite results (there are a lot of different target tests which >>>> expect a particular output), it is better to do this on stabilized >>>> GCC and stage3 is the best time for this. In any case I'll approve >>>> patches only if you have successful bootstraps and no GCC testsuite >>>> regression on x86-64, ppc64le/be, aarhc64, i686. >>>> Also you have a lot of compile time performance issues which you >>>> need to address. So I guess you will be overwhelmed by new >>>> different target PRs after committing the patches if you will do >>>> this now. You will have more time and less pressure work if you >>>> commit these patches in April. >>> >>> Hmmmmm, I'll test the targets I can get first. I'll figure out the >>> other targets later. >>> >> The compiler farm can provide access to a bunch of targets and the >> community may be able to help with access to others if needed. > > I applied for cfarm access the other day, I'll try to use it. Thanks. No problem. If you need some Linux targets not on the cfarm, let me know. I can probably help with hppa/sparc at least and I know someone with alpha, mips.
