From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 839B03858D37 for ; Mon, 26 Sep 2022 23:43:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 839B03858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664235832; 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=Wpv8Uso/7K1beODXWIjO1w5EvzLddGITgaeUTuypJ6k=; b=jLIABNI/Ed2JEFwVlXxwmRi8vr4LHa3aLk5UljeVJLtkjWCavlDpdX6lZ+y6WiWlRjyR8w CenxP6HL9yp4t8gWhBsBDJywhg7/XuFiqyHcmQvYzc2ejfhNB5B6rxdbfvcERsOy1uP6AQ OgODetvnKydTvsaijQrYuOxy2z6Qw2Q= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-635-pn31YPV0OxOO28t2h-FuJQ-1; Mon, 26 Sep 2022 19:43:48 -0400 X-MC-Unique: pn31YPV0OxOO28t2h-FuJQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 912CA811E81; Mon, 26 Sep 2022 23:43:48 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.194]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4E7C440C6EC2; Mon, 26 Sep 2022 23:43:48 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 28QNhjO12971481 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 27 Sep 2022 01:43:46 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 28QNhjEG2970106; Tue, 27 Sep 2022 01:43:45 +0200 Date: Tue, 27 Sep 2022 01:43:44 +0200 From: Jakub Jelinek To: Jeff Law Cc: "H.J. Lu" , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Ignore debug insns with CONCAT and CONCATN for insn scheduling Message-ID: Reply-To: Jakub Jelinek References: <20220902143639.2464892-1-hjl.tools@gmail.com> <93fb0c92-c6a4-450b-2d0a-eddd30543fae@gmail.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP 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 Mon, Sep 26, 2022 at 05:23:45PM -0600, Jeff Law via Gcc-patches wrote: > > On 9/26/22 13:52, H.J. Lu wrote: > > On Sat, Sep 24, 2022 at 1:37 PM Jeff Law wrote: > > > > > > On 9/21/22 16:11, H.J. Lu wrote: > > > > On Wed, Sep 7, 2022 at 10:03 AM Jeff Law via Gcc-patches > > > > wrote: > > > > > > > > > > On 9/2/2022 8:36 AM, H.J. Lu via Gcc-patches wrote: > > > > > > CONCAT and CONCATN never appear in the insn chain. They are only used > > > > > > in debug insn. Ignore debug insns with CONCAT and CONCATN for insn > > > > > > scheduling to avoid different insn orders with and without debug insn. > > > > > > > > > > > > gcc/ > > > > > > > > > > > > PR rtl-optimization/106746 > > > > > > * sched-deps.cc (sched_analyze_2): Ignore debug insns with CONCAT > > > > > > and CONCATN. > > > > > Shouldn't we be ignoring everything in a debug insn? I don't see why > > > > > CONCAT/CONCATN are special here. > > > > Debug insns are processed by insn scheduling. I think it is to improve debug > > > > experiences. It is just that there are no matching usages of CONCAT/CONCATN > > > > in non-debug insns. > > > But from a dependency standpoint ISTM all debug insn can be ignored. I > > > still don't see why concat/concatn should be special here. > > > > > I tried to ignore everything in a debug insn. It caused many regressions in > > the GCC testsuite. > Not terribly useful -- what failed and why? I think the design for debug insns in the scheduler is that they do affect scheduling decisions, but what is in debug insns should only affect actual scheduling of the debug insns and not the rest. So it wouldn't surprise me if ignoring everything in a debug insn broke a lot. But I admit I never fully understood how it works, hopefully Alex or Vlad do. Jakub