From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23572 invoked by alias); 6 Dec 2019 22:47:45 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 23559 invoked by uid 89); 6 Dec 2019 22:47:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,KAM_SHORT,SPF_PASS autolearn=ham version=3.3.1 spammy=Matthew, matthew, H*c:alternative X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Dec 2019 22:47:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1575672461; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=So/4KFci5UM+8Ug8j6JbF+fE+7aORKfeYcQ808be3yQ=; b=DL3fZuQSOvhCOTS9gRmFN5oXfDRw3knnoG9twHVJk1rCG8pSJcHmJo43/ydudU9x4r9zZW Ip64I2or2YfGsc1dwwRhPuHQgllHf5ur4xqi2hNbIcD5qn8zWYOCY6WL4dNld14zxKChIw rIwtdibGH4iLQQOWxAg7ZKennJW3wpU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-50-rU0e53vHMNiuL6486TOCMA-1; Fri, 06 Dec 2019 17:47:36 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 74CDA1005502; Fri, 6 Dec 2019 22:47:35 +0000 (UTC) Received: from ovpn-112-27.phx2.redhat.com (ovpn-112-27.phx2.redhat.com [10.3.112.27]) by smtp.corp.redhat.com (Postfix) with ESMTP id B61BD19C4F; Fri, 6 Dec 2019 22:47:33 +0000 (UTC) Message-ID: <2453216e1135356bf637f20f1e5e8540d67aafc0.camel@redhat.com> Subject: Re: [mid-end] Add notes to dataflow insn info when re-emitting (PR92410) From: Jeff Law Reply-To: law@redhat.com To: Matthew Malcomson , "gcc-patches@gcc.gnu.org" Cc: "rguenther@suse.de" , nd , "ian@airs.com" , Martin Liska Date: Fri, 06 Dec 2019 22:47:00 -0000 In-Reply-To: References: User-Agent: Evolution 3.34.2 (3.34.2-1.fc31) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00469.txt.bz2 On Tue, 2019-11-12 at 09:11 +0000, Matthew Malcomson wrote: > In scheduling passes, notes are removed with `remove_notes` before > the > > scheduling is done, and added back in with `reemit_notes` once the > > scheduling has been decided. > > > > This process leaves the notes in the RTL chain with different insn > uid's > > than were there before. Having different UID's (larger than the > > previous ones) means that DF_INSN_INFO_GET(insn) will access outside > of > > the allocated array. > > > > This has been seen in the `regstat_bb_compute_calls_crossed` > function. > > This patch adds an assert to the `regstat_bb_compute_calls_crossed` > > function so that bad accesses here are caught instead of going > > unnoticed, and then avoids the problem. > > > > We avoid the problem by ensuring that new notes added by > `reemit_notes` have an > > insn record given to them. This is done by adding a call to > > `df_insn_create_insn_record` on each note added in `reemit_notes`. > > `df_insn_create_insn_record` leaves this new record zeroed out, which > appears > > to be fine for notes (e.g. `df_bb_refs_record` already does not set > > anything except the luid for notes, and notes have no dataflow > information to > > record). > > > > We add the testcase that Martin found here > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410#c2 . > > This testcase fails with the "regstat.c" change, and then succeeds > with the > > "haifa-sched.c" change. > > > > There is a similar problem with labels, that the `gcc_assert` catches > > when running regression tests in gcc.dg/fold-eqandshift-1.c and > > gcc.c-torture/compile/pr32482.c. > > This is due to the `cfg_layout_finalize` call in `bb-reorder.c` > emitting > > new labels for the start of the newly created basic blocks. These > labels are > > not given a dataflow df_insn_info member. > > > > We solve this by manually calling `df_recompute_luids` on each basic > > block once this pass has finished. > > > > Testing done: > > Bootstrapped and regression test on aarch64-none-linux-gnu native. > > > > gcc/ChangeLog: > > > > 2019-11-12 Matthew Malcomson > > > > PR middle-end/92410 > > * bb-reorder.c (pass_reorder_blocks::execute): Recompute > > dataflow luids once basic blocks have been reordered. > > * haifa-sched.c (reemit_notes): Create df insn record for > each > > new note. > > * regstat.c (regstat_bb_compute_calls_crossed): Assert every > > insn has an insn record before trying to use it. > > > > gcc/testsuite/ChangeLog: > > > > 2019-11-12 Matthew Malcomson > > > > PR middle-end/92410 > > * gcc.dg/torture/pr92410.c: New test. > OK jeff