From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id 6E1113858C51 for ; Mon, 21 Mar 2022 13:49:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6E1113858C51 Received: by mail-ed1-x536.google.com with SMTP id k10so4174206edj.2 for ; Mon, 21 Mar 2022 06:49:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zZKtym+I3INIvtQJaU2D6lpXkr6r8KEUSjM6PGhaQKA=; b=Nw/33wEtpjBlvP3srVvkLcEe24bO3ODfv6l8HmlTIRR/aJr8M49BfZuq18oPqRFQ5p LvJxrnhWgm0skdvW1xc3lz7sxEGXJsedeNJJ1iEkGHoD4O/8EfJXml3fg4FCCQlnWMip 9/7xTDTEwv/oDLihwFvWla6tRxoaPiXDbPs8/L6Mb7Ap2zrUw0rAfAAqA6INdw4xc3hP rEIOZNFG8vUVJAxZcI7aEv2VFsvcRmDLQROz4ncQBsxuECTK4ihv6RhqUPAfOCosIHHx Ls6JTe1R7APTS/pswvNbavSZPnBXuKSXGf5+9+EwSXs2f8h4gYrchr+oe4RDdT3vS4aq ZzOQ== X-Gm-Message-State: AOAM530cgYIUgm8aSbOPvzGrMXmYN/LTYmHq8bsalrlkJ5gKsSJAcLWG qsqKVwlNu0krZtIc77ZsdMxfYok02oY8yZswdUY= X-Google-Smtp-Source: ABdhPJxK+fAmQ2nzhDxm77flIcqMkups9qKFSoTtnLACyCaEwj7OV3l9pPhGiFvglZLQRX3qLlYtfObTgGIw5t1GXHg= X-Received: by 2002:aa7:c1cd:0:b0:419:fdb:e17e with SMTP id d13-20020aa7c1cd000000b004190fdbe17emr15925933edp.364.1647870578138; Mon, 21 Mar 2022 06:49:38 -0700 (PDT) MIME-Version: 1.0 References: <20220222135513.GA1591@delia.home> <2efa0fec-aea3-3b9e-61f2-7f0f332668e7@suse.de> In-Reply-To: From: Richard Biener Date: Mon, 21 Mar 2022 14:49:27 +0100 Message-ID: Subject: Re: [PING^2][PATCH][final] Handle compiler-generated asm insn To: Tom de Vries Cc: Alexandre Oliva , GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2022 13:49:41 -0000 On Mon, Mar 21, 2022 at 12:50 PM Tom de Vries wrote: > > On 3/21/22 08:58, Richard Biener wrote: > > On Thu, Mar 17, 2022 at 4:10 PM Tom de Vries via Gcc-patches > > wrote: > >> > >> On 3/9/22 13:50, Tom de Vries wrote: > >>> On 2/22/22 14:55, Tom de Vries wrote: > >>>> Hi, > >>>> > >>>> For the nvptx port, with -mptx-comment we have in pr53465.s: > >>>> ... > >>>> // #APP > >>>> // 9 "gcc/testsuite/gcc.c-torture/execute/pr53465.c" 1 > >>>> // Start: Added by -minit-regs=3: > >>>> // #NO_APP > >>>> mov.u32 %r26, 0; > >>>> // #APP > >>>> // 9 "gcc/testsuite/gcc.c-torture/execute/pr53465.c" 1 > >>>> // End: Added by -minit-regs=3: > >>>> // #NO_APP > >>>> ... > >>>> > >>>> The comments where generated using the compiler-generated equivalent of: > >>>> ... > >>>> asm ("// Comment"); > >>>> ... > >>>> but both the printed location and the NO_APP/APP are unnecessary for a > >>>> compiler-generated asm insn. > >>>> > >>>> Fix this by handling ASM_INPUT_SOURCE_LOCATION == UNKNOWN_LOCATION in > >>>> final_scan_insn_1, such what we simply get: > >>>> ... > >>>> // Start: Added by -minit-regs=3: > >>>> mov.u32 %r26, 0; > >>>> // End: Added by -minit-regs=3: > >>>> ... > >>>> > >>>> Tested on nvptx. > >>>> > >>>> OK for trunk? > >>>> > >>> > >> > >> Ping^2. > >> > >> Tobias just reported an ICE in PR104968, and this patch fixes it. > >> > >> I'd like to known whether this patch is acceptable for stage 4 or not. > >> > >> If not, I need to fix PR104968 in a different way. Say, disable > >> -mcomment by default, or trying harder to propagate source info on > >> outlined functions. > > > > Hi, > > thanks for the review. > > > Usually targets use UNSPECs to emit compiler-generated "asm" > > instructions. > > Ack. [ I could go down that route eventually, but for now I'm hoping to > implement this without having to change the port. ] > > > I think an unknown location is a reasonable but not > > the best way to identify 'compiler-generated', we might lose > > the location through optimization. (why does it not use > > the INSN_LOCATION?) > > > > I don't know. FWIW, at the time that ASM_INPUT_SOURCE_LOCATION was > introduced (2007), there was no INSN_LOCATION yet (introduced in 2012), > only INSN_LOCATOR, my guess is that it has something to do with that. > > > Rather than a location I'd use sth like DECL_ARTIFICIAL to > > disable 'user-mangling', do we have something like that for > > ASM or an insn in general? > > Haven't found it. > > > If not maybe there's an unused > > bit on ASMs we can enable this way. > > Done. I've used the jump flag for that. > > Updated, untested patch attached. > > Is this what you meant? Hmm. I now read that ASM_INPUT is in every PATTERN of an insn and wonder how this all works out there. That is, by default the ASM_INPUT would be artificial (for regular define_insn) but asm("") in source would mark them ASM_INPUT_USER_P or so. But then I know nothing here. I did expect us to look at ASM_OPERANDS instead of just ASM_INPUT (but the code you are changing is about ASM_INPUT). That said, the comments should probably explicitely say this is about ASM_INPUT in an ASM_OPERANDS instruction template, not some other pattern. But yes, this was kind-of what I meant. Any considerations from others? Thanks, Richard. > > Thanks, > - Tom