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

[Sam James <sam@gentoo.org>]

Lehua Ding <lehua.ding@rivai.ai> writes:

> Hi Sam,
>
> On 2023/11/18 16:06, Sam James wrote:
>> Lehua Ding <lehua.ding@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.