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

[Sam James]

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.

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

thanks,
sam