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.
--
Best,
Lehua (RiVAI)
