From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by sourceware.org (Postfix) with ESMTPS id 687A13858D20 for ; Tue, 14 Nov 2023 09:06:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 687A13858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 687A13858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::12e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699952817; cv=none; b=H3t++3gWt/MTVbEa7MyxseedpfQ+deORL5Im5O/2ACjBOiQU7wPGxQn+r6PersoeB0azX/uSq+nFzo0RQOGusVlvI7eMB2jPmY3n3JXtIIbxV+fuFu351lcFsyxPiDsQf8kGABxfEWn1ANFKOL6Hi8sn0fiQs9HacPEprknjBhc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699952817; c=relaxed/simple; bh=H2B8/4+EfK/JjeXXoJxrWMVAP9FAEZKej/+s04WmMmA=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=KA+FOi9kF1v4QDPg4QATPiyrLIcmlRaGPwD+AN9gjlxrO15Ye0XWpWO1gROw6O3BL1yNqzXH9wViDhz7fT36cJoNENHgd5VbrCk+ocMi+lxtb1RihMBad8b0ym6uUkXvzoltogYgju3wKhajDtFkGRY55IQ+m+DppYSqKr+QNDQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-507a62d4788so7662050e87.0 for ; Tue, 14 Nov 2023 01:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699952814; x=1700557614; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=A5wniCkSjJCR0pz5GGMnvRvDqCjUBf1FGWB9m5fMyE8=; b=e9eV/NQBPYpcHvHBx6eG4wFvxWSjCV45Q2xzHoQw3NpRWC1pKWb753QPijtC7w2s+t 6or+jPq/HuuoP4fhZLAN6yUCsiBY7f8Ak/4cotlq4yWE4WfNjWrICbAFdGMGWgbWGrGw uC19heMJTjywwFcsho3Fn6DtbJmLkwerTRBhNEuQymHitENBlFc3ZR6y7WtG0WH22Zue WwsA9YdA2uBt1ifnrtzLx55cyajQ4Bq/LQfOEXO5nR+iLkgL7AumU83EfLFS8XWMj9Ov QonTeBkGPdWav/9E87JsCu/KTWEUAvzLSyzDgy5p/ZafGYMgMKCZ6/q91IWhvOTzkUI+ ObAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699952814; x=1700557614; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=A5wniCkSjJCR0pz5GGMnvRvDqCjUBf1FGWB9m5fMyE8=; b=l7Rs3WZpJKnrkJUqMJEIN1XdL1jWf/Av4r6A31FeodZt93IONgYHSGnUXG6orOHkZG 9g5Vm0gTKyqK/9OCGyjQgAvpVJp53JVEkcSQQyCsNmHnDMk1zq8FwM2w/+MYzYSLsHtf GMaV55UZcfjCByeaGHGS/MwlCm8nWxRTXACTLUfV9C9R5TTu07S55rfz3Gbxzl5uPH2V et7D1R7m/4VQLtbE0kL7iNuknUKSoxBglwkIOHLae6ZqOyufiUI6MjJWE90i8CjNoTnt cbgfNeF0AIhG5gTR76c82xhqNnPgS2I872oaPo36V0mVtmd3C0tZaLcd+9VcnTE5yP/5 VwXQ== X-Gm-Message-State: AOJu0Yye6zwpgVNKUIHst3ufMx1F+uHNWt+jAsukgAxVUR2yxOU8b1mN vVpAZvRpVw3sk8dh8IbR68/CHhffg2Lj4SwvQGpeBlygOMQ= X-Google-Smtp-Source: AGHT+IGYFwpGE6sTZGlXKIxI1hdz6ZGnoAQHXyDXhOb+F7pv/u71x1k7ZzQFiBsOL+4B0cvVfB/wlv5RNI8iX+x/mQg= X-Received: by 2002:a19:6917:0:b0:508:1a2c:46d0 with SMTP id e23-20020a196917000000b005081a2c46d0mr5657173lfc.15.1699952813481; Tue, 14 Nov 2023 01:06:53 -0800 (PST) MIME-Version: 1.0 References: <20231112120817.2635864-1-lehua.ding@rivai.ai> <20231112120817.2635864-2-lehua.ding@rivai.ai> <040fba3b-4f8d-f8cf-df7a-5b77ac251148@redhat.com> <1A588F107664DFA6+96d02d06-07bd-4e79-9493-5e0824d672dd@rivai.ai> In-Reply-To: <1A588F107664DFA6+96d02d06-07bd-4e79-9493-5e0824d672dd@rivai.ai> From: Richard Biener Date: Tue, 14 Nov 2023 10:03:22 +0100 Message-ID: Subject: Re: [PATCH V3 1/7] df: Add DF_LIVE_SUBREG problem To: Lehua Ding Cc: Vladimir Makarov , gcc-patches@gcc.gnu.org, richard.sandiford@arm.com, juzhe.zhong@rivai.ai Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Nov 14, 2023 at 9:38=E2=80=AFAM Lehua Ding wr= ote: > > > > On 2023/11/14 16:14, Richard Biener wrote: > > On Mon, Nov 13, 2023 at 11:39=E2=80=AFPM Vladimir Makarov 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 regist= ers > >>> who's mode size is a multiple of nature size and eventually a small p= ortion > >>> 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 p= esudo > >>> live in/out, partial_in/out mean the subregs of the pesudo are live i= n/out, > >>> and range_in/out indicates which part of the pesudo is live. all_in/o= ut 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 Sandifor= d > >> 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 us= ed > >> DFA but it made LRA so slow that I had to introduce own data structure= s > >> 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 wh= en > >> 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? I suggest you farm bugzilla for the compile-time-hog / memory-hog testcases= . I do have a set of "large" testcases. Scanning results points at PRs 36262, 37448, 39326, 69609 all having RA in the 20% area at -O0 -g. It's also a good idea to take say cc1files (set of preprocessed sources that produce GCCs cc1) and look at the overall impact of compile-time and memory-usage of a change on those which are representative for "normal" TUs as opposed to the PRs above which often are large machine-generated TUs (an important area where GCC usually shines, at least at -O1). Richard. > -- > Best, > Lehua (RiVAI) > lehua.ding@rivai.ai