From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id E0242385800D; Tue, 17 Nov 2020 08:57:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E0242385800D Received: by mail-wr1-x433.google.com with SMTP id m6so5156880wrg.7; Tue, 17 Nov 2020 00:57:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:to:cc:references:from:subject:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YvHnUmiLmxXGbKRwvM+mIMYr1/IyRsnmLH5TqtMRZfA=; b=pX+neillkJuZUJAe1HeV+Kidj3Rz5NdbTkRMu6i20byFfeZ/aaTAjdu/yUDzd+xWUV l3sBvc9m4B8s47N35Fp4fyP0HT6WerAFxbcQD4MsIhV87OYluQTFSOzUBruHDirFMR17 LQ1kNcJWEfaQiTrU6+PW7Gja8Kx/agpaXg8TniTY86uB71YOi35MN3kgTETyG11KocA/ AZ0BG49bLa7CziE4djqxi0oFnbURvfHV8LTM1x5fXvvP+5enhdfDA6uKMQXkKOOithC1 9WHJ+BNGEUHF8UlRB86OjX95lnFChs8p+8WRiDiedr+i1GOhdp7MvDvJJbANqGjEWaw5 JPqQ== X-Gm-Message-State: AOAM532Sy+gSIWCWBVFVxbxI3TWjiJ5UWBET/4qJ0QYb+uUbxQtk9UUj TCdBeFHHnBIa2apiiOUS0ykIxktevxE= X-Google-Smtp-Source: ABdhPJxx9u63A6DRSxpfrf1SgemjbEhJ9h4n1RRhzH/USEmDvVjesPmsSPhh2mJQVA2FpUPRkytuWg== X-Received: by 2002:a5d:6692:: with SMTP id l18mr22551145wru.44.1605603468533; Tue, 17 Nov 2020 00:57:48 -0800 (PST) Received: from ?IPv6:2001:b07:6468:f312:c8dd:75d4:99ab:290a? ([2001:b07:6468:f312:c8dd:75d4:99ab:290a]) by smtp.googlemail.com with ESMTPSA id k1sm23185154wrp.23.2020.11.17.00.57.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Nov 2020 00:57:47 -0800 (PST) Sender: Paolo Bonzini To: Jeff Law , Segher Boessenkool Cc: Xionghu Luo , "gcc@gcc.gnu.org" , jakub@redhat.com, ebotcazou@gcc.gnu.org, abel@gcc.gnu.org References: <20201113135516.GU2672@gate.crashing.org> From: Paolo Bonzini Subject: Re: CSE deletes valid REG_EQUAL? Message-ID: <1a32cf70-8b10-ebad-e371-97495788b14d@gnu.org> Date: Tue, 17 Nov 2020 09:57:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 08:57:51 -0000 On 17/11/20 02:12, Jeff Law wrote: >> Removing all REG_EQUAL notes for regs that become dead anywhere That's not what it does. >> seems to just be a thinko? All pseudos are dead somewhere! (Yeah okay, >> infinite loops, but other than that.) > > Yea, but the code which wipes the notes probably has no sense of where > in the RTL stream the note is valid and where it is not.  So it does the > fairly dumb thing and just ends up wiping them all away because as you > noted, most pseudos have a death somewhere. It shouldn't wipe all of them. It doesn't look at all REG_EQUAL notes in the function; it looks at the notes one insn at a time, and wipes the REG_EQUAL notes for registers that are dead _at that insn_. See how the loop uses DF_INSN_EQ_USES: for (use_rec = DF_INSN_EQ_USES (insn); *use_rec; use_rec++) { df_ref use = *use_rec; if (DF_REF_REGNO (use) > FIRST_PSEUDO_REGISTER && (DF_REF_FLAGS (use) & DF_REF_IN_NOTE) && ! bitmap_bit_p (live, DF_REF_REGNO (use))) { deleted = true; break; } } and it is called as df_kill_notes (insn, live); > One might argue that the code is OK as-is, but just needs to be run > later. After cse2 would be the most logical location since CSE is > probably the heaviest user of the notes. But I'd worry that the > problems referenced in c#2 of bz51505 could crop up in other contexts > than just combine. Yeah, it was a design decision of DF to ignore REG_EQUAL/REG_EQUIV notes when computing liveness and adding REG_DEAD notes[1]. Unfortunately this all predates my involvement in DF and I'm also unfamiliar with how REG_DEAD and REG_EQUAL notes interacted in flow.c times. But it's very unlikely that after ~10 years there aren't more places with the same issue that PR51505 worked around. Paolo [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51505#c3