From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70216 invoked by alias); 2 Oct 2019 09:39:33 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 70204 invoked by uid 89); 2 Oct 2019 09:39:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=solves X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Oct 2019 09:39:27 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1535C1000; Wed, 2 Oct 2019 02:39:25 -0700 (PDT) Received: from e120077-lin.cambridge.arm.com (unknown [10.2.206.225]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 636483F706; Wed, 2 Oct 2019 02:39:24 -0700 (PDT) Subject: Re: syncing the GCC vax port, atomic issue To: Jeff Law , coypu@sdf.org Cc: gcc@gcc.gnu.org, port-vax@netbsd.org References: <20190330090306.GA29299@SDF.ORG> <180b1040-215f-e6dc-599b-394d91761d88@redhat.com> <20190920111532.GB15685@SDF.ORG> <20190920210434.GA13838@SDF.ORG> <010f52a3-98ed-47f9-38af-2560193b6a52@redhat.com> <20190920220756.GA10628@SDF.ORG> <20190921011835.GA5931@SDF.ORG> <86ce35ec-9471-66bc-bf0d-72a1b5d7813e@redhat.com> From: "Richard Earnshaw (lists)" Message-ID: <14f417df-83f4-13ac-9f10-73b1192b74f8@arm.com> Date: Wed, 02 Oct 2019 09:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <86ce35ec-9471-66bc-bf0d-72a1b5d7813e@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2019-10/txt/msg00020.txt.bz2 On 01/10/2019 20:43, Jeff Law wrote: > On 9/20/19 7:18 PM, coypu@sdf.org wrote: >> On Fri, Sep 20, 2019 at 10:07:59PM +0000, coypu@sdf.org wrote: >>> Introducing the reversed jbb* patterns doesn't seem to help with the >>> original issue. It crashes building libatomic. >> >> My loose understanding of what is going on: >> - GCC emits this atomic in expand. >> - When cleaning up, it looks for optimizations. >> - It decides this is a branch to another branch situation, so maybe >> can be improved. >> - This fails to output an instruction for unrelated reasons. >> - Hit an assert. >> >> I don't think that we should be trying to combine regular branch + >> atomic branch in very generic code. > I can see how you might think that, but the way the RTL optimizers work, > particularly the combiner is it tries to smash together two or more > insns that are related by dataflow into a single insn (I'm > over-simplifying, but it's good enough for this discussion). > > That's an inherent design decision for the combiner, it's not likely to > change. If you want to prevent the combiner from doing that, you have > to use UNSPECs > > Jeff > There are some target hooks in combine that might help here. targetm.cannot_copy_insn_p and targetm.legitimate_combined_insn. The former is used more widely than just combine, so you might need to be careful that it doesn't adversely affect other optimizations. The latter relies on spotting that the combined insn is doing something stupid even though it matches a pattern in the back-end. So it may be that neither really solves your problem in this case. R.