Re: [PATCH V3 4/7] ira: Support subreg copy

[Vladimir Makarov <vmakarov@redhat.com>]

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).

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.

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.

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.