On Mon, Nov 13, 2023 at 11:39 PM Vladimir Makarov <vmaka...@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. Richard. >