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

[Lehua Ding <lehua.ding@rivai.ai>]

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)