Re: [PATCH V3 1/7] df: Add DF_LIVE_SUBREG problem

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

On 2023/11/14 16:14, Richard Biener wrote:
> On Mon, Nov 13, 2023 at 11:39 PM Vladimir Makarov <vmakarov@redhat.com> wrote:
>>
>>
>> On 11/12/23 07:08, Lehua Ding wrote:
>>> This patch adds a live_subreg problem to extend the original live_reg to
>>> track the liveness of subreg. We will only try to trace speudo registers
>>> who's mode size is a multiple of nature size and eventually a small portion
>>> of the inside will appear to use subreg. With live_reg problem, live_subreg
>>> prbolem will have the following output. full_in/out mean the entire pesudo
>>> live in/out, partial_in/out mean the subregs of the pesudo are live in/out,
>>> and range_in/out indicates which part of the pesudo is live. all_in/out is
>>> the union of full_in/out and partial_in/out:
>>>
>> I am not a maintainer or reviewer of data-flow analysis framework and
>> can not approve this patch except changes in regs.h.  Richard Sandiford
>> or Jeff Law as global reviewers probably can do this.
>>
>> As for regs.h changes, they are ok for me after fixing general issues I
>> mentioned in my previous email (two spaces after sentence ends in the
>> comments).
>>
>> I think all this code is a major compiler time and memory consumer in
>> all set of the patches.  DF analysis is slow by itself even when only
>> effective data structures as bitmaps are used but you are introducing
>> even slower data structure as maps (I believe better performance data
>> structure can be used instead).  In the very first version of LRA I used
>> DFA but it made LRA so slow that I had to introduce own data structures
>> which are faster in case of massive RTL changes in LRA.  The same
>> problem exists for using generic C++ standard library data as vectors
>> and maps for critical code.  It is hard to get a needed performance when
>> the exact implementation can vary or be not what you need, e.g. vector
>> initial capacity, growth etc.  But again the performance issues can be
>> addressed later.
> 
> I think the important bit should be the subreg live analysis should be
> opt-in and when not enabled shouldn't have a bad effect on memory
> usage and compile-time.  At -O0 and -O1 RA consumes a major
> amount of compile-time.

This is perfectly fine, the code inside the live_subreg problem has a 
branch that goes through similar logic to live_reg if it finds no subreg 
inside the program. Then when the optimization level is less than 2, it 
doesn't track the subreg. By the way, I'd like to ask you if you have 
certain programs where RA has a big impact on compilation time to offer? 
Or any suggestions about it?

-- 
Best,
Lehua (RiVAI)
lehua.ding@rivai.ai