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.
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.
You changes are massive and in a critical part of GCC, it is better to
do all of this on public git branch in order to people can try this and
test their targets.
Okay, I'll try.
But it is up to you to decide when submit the patches. Still besides
approval of your patches, you need successful testing. If new testsuite
failures occur after submitting the patch and they are not fixed during
short period of time, the patches should be reverted.
1. live_subreg problem
2. conflict_hard_regs check refactoring
3. use object instead of allocno to create copies
4. support subreg coalesce
4.1 ira: Apply live_subreg data to ira
4.2 lra: Apply live_subreg data to lra
4.3 ira: Support subreg liveness track
4.4 lra: Support subreg liveness track
So for the two patches about LRA, maybe you can stop review and wait
for the revised patchs.
Sure. So far I only had a quick glance on them.
--
Best,
Lehua (RiVAI)
