From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21216 invoked by alias); 10 Feb 2018 06:35:14 -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 21198 invoked by uid 89); 10 Feb 2018 06:35:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=abuse, FSM, fsm X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 10 Feb 2018 06:35:12 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3D676DF15F; Sat, 10 Feb 2018 06:35:11 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-4.rdu2.redhat.com [10.10.112.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 67AAB5D720; Sat, 10 Feb 2018 06:35:09 +0000 (UTC) Subject: Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers To: Alexandre Oliva Cc: Alan Modra , Jakub Jelinek , Jason Merrill , Richard Biener , GCC Patches References: <20171110023448.28164-9-aoliva@redhat.com> <20180124171232.GG2063@tucnak> <20180209035334.GF3846@bubble.grove.modra.org> <6e28e34e-681d-bebb-d815-569eee148de5@redhat.com> From: Jeff Law Message-ID: <6dc55573-7535-6b75-9ef4-823738d561c9@redhat.com> Date: Sat, 10 Feb 2018 06:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00571.txt.bz2 On 02/09/2018 09:39 PM, Alexandre Oliva wrote: > On Feb 9, 2018, Alexandre Oliva wrote: > >> On Feb 9, 2018, Jeff Law wrote: >>> On 02/08/2018 08:53 PM, Alan Modra wrote: >>>> On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote: >>>>> Here's what I checked in, right after the LVU patch. >>>>> >>>>> [IEPM] Introduce inline entry point markers >>>> >>>> One of these two patches breaks ppc64le bootstrap with the assembler >>>> complaining "Error: view number mismatch" when compiling >>>> libdecnumber. >>>> >>> I've just passed along a similar failure (.i, .s and command line >>> options) to Alex for ppc64 (be) building glibc. > >> Thanks. So, I'm told there are more such issues, that non-asm insn >> length attrs can't be relied on at this time to be nonzero only when the >> actual length is not zero. > > I wonder... In the previously-posted patch, we still regard call insns > are advancing PC. I think that's a safe assumption, but... are there > any other kinds of patterns we could recognize that would certainly > generate an actual PC-changing insn? How about jump insns? How about > insns that are SETs, or PARALLELs containing at least one SET? Does > anyone see any risk in recognizing those when the length attr is, > conservatively or not, deemed unreliable? Any other paterns we could > recognize to that end? So given what I've seen in the ARM port, I don't think we can generally assume any insn advances the PC. Here's why. On the ARM there's a little state machine that's used to implement conditional execution. When we're in certain states the backend will generate no code for certain JUMP_INSNs and change the state. That's fine and dandy. THe problem is we can't actually tell outside the ARM backend when that's happened! You might think we could embed tests of the FSM within the length computation. But the state of the FSM is only valid during assembly output (e.g. final). But insn lengths are set up during branch shortening and if you query the length attribute you get value computed by branch shortening. The only way around this would be to do what I would consider some interface abuse and query insn_min_length (not to be confused with get_attr_min_length). Then we wouldn't get the cached version and we could do queries of the state machine on the fly in dwarf2out_var_location. But it seems rather icky and I haven't even been able to convince myself it's really safe. And while this is specific to the ARM and JUMP_INSNs, I can easily envision scenarios where other ports could use the same kind of little state machine for standard INSNs (PA to generate add,tr) or even CALL_INSNs (target dependent optimization of tail calls). You also have to worry about ports that try to optimize away nop-insns that snuck through the optimizers. I once worked on a port that couldn't encode a register self copy. So when one snuck through the optimizers, we had to deal with it in the output code and I know I've seen other instances where ports tried to compensate for nop-insns that snuck through. So in the end I don't think you can assume that any given insn advances the PC. The closest we have is the length attribute, but it has always supposed to have been conservatively correct for the purposes of branch shortening. ie, it can never return a length less than the actual length, but it is allowed to return a length longer than the actual length. Jeff