From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113925 invoked by alias); 5 Dec 2017 21:54:53 -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 113899 invoked by uid 89); 5 Dec 2017 21:54:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=ira.c, UD:ira.c, irac X-HELO: mail-wr0-f177.google.com Received: from mail-wr0-f177.google.com (HELO mail-wr0-f177.google.com) (209.85.128.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Dec 2017 21:54:51 +0000 Received: by mail-wr0-f177.google.com with SMTP id x49so1846091wrb.13 for ; Tue, 05 Dec 2017 13:54:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=XlXUvFDlsW6kLbDG5GRjeuR4TDMkp8Vi2HNgd2NNDH4=; b=pGVdNVMlL6FzPn24vLmBrg8LQCsJ1KQgod//7f1jLmN2R7foiyXnoI2R1UCiPZYPT0 Dnul5F98sk9xcJh8rHr3lF+pLtv6DSCoz428UGqsJt/QnOOYiAgoF9NLDB1ehW8v84Ol BQFwAevMtVA9Q1iXocoBSgb+rpQUKUfIsBPgIhhvtVuhwWcdruI7a/cc3N6tQh4bOHEe 4rtnrdK1i/Z8os/hxe2o1SovjXhsLzOa1fJIGIzXAvMSuhfiOtr8gqm9Lae/HhdBBxUw cBWqZ6HOE9VzO9fe/iQdtiGGSdm1HXVBxTycNqiuSae2Km/o1iBBIMcTIVzvv/QO2ylu Zk6Q== X-Gm-Message-State: AJaThX6q8eb9mfEHrVdnXuBcvrpa4kayNimCb2mCPkUlflOQSkJLL01w mATd64KkEdcUuWa0beKdrKwp6d2UdWM= X-Google-Smtp-Source: AGs4zMbWLsN6NUmugwgIATFZgSVF7CDbDVbsdl/bq0ikzG/D3PcAlC06CZGJJ/1QBqQmMho9yvF1Yg== X-Received: by 10.223.179.209 with SMTP id x17mr18201080wrd.145.1512510888751; Tue, 05 Dec 2017 13:54:48 -0800 (PST) Received: from localhost ([2.25.234.120]) by smtp.gmail.com with ESMTPSA id 34sm1190437wra.39.2017.12.05.13.54.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 05 Dec 2017 13:54:47 -0800 (PST) From: Richard Sandiford To: Jeff Law Mail-Followup-To: Jeff Law ,gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Cc: gcc-patches@gcc.gnu.org Subject: Re: [024/nnn] poly_int: ira subreg liveness tracking References: <871sltvm7r.fsf@linaro.org> <87zi8hpz8r.fsf@linaro.org> <2439d6a5-a824-33bb-b298-eb51a72ce12e@redhat.com> Date: Tue, 05 Dec 2017 21:54:00 -0000 In-Reply-To: <2439d6a5-a824-33bb-b298-eb51a72ce12e@redhat.com> (Jeff Law's message of "Tue, 28 Nov 2017 13:30:00 -0700") Message-ID: <87mv2wc02h.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-12/txt/msg00267.txt.bz2 Jeff Law writes: > On 10/23/2017 11:09 AM, Richard Sandiford wrote: >> Normmaly the IRA-reload interface tries to track the liveness of >> individual bytes of an allocno if the allocno is sometimes written >> to as a SUBREG. This isn't possible for variable-sized allocnos, >> but it doesn't matter because targets with variable-sized registers >> should use LRA instead. >> >> This patch adds a get_subreg_tracking_sizes function for deciding >> whether it is possible to model a partial read or write. Later >> patches make it return false if anything is variable. >> >> >> 2017-10-23 Richard Sandiford >> Alan Hayward >> David Sherwood >> >> gcc/ >> * ira.c (get_subreg_tracking_sizes): New function. >> (init_live_subregs): Take an integer size rather than a register. >> (build_insn_chain): Use get_subreg_tracking_sizes. Update calls >> to init_live_subregs. > OK. > > Note this is starting to get close to the discussion around CLOBBER_HIGH > vs using a self set with a low subreg that we're having with Alan on > another thread in that liveness tracking of subregs of SVE regs could > potentially use some improvements. > > When I quickly looked at the subreg handling in the df infrstructure my > first thought was that it might need some updating for SVE. I can't > immediately call bits for poly_int/SVE in the patches to-date. Have you > dug in there at all for the poly_int/SVE work? Yeah, although the subreg tracking in this patch is specific to reload, I thought we had something similar for LRA. I couldn't find anything though, and the static type checking of poly_ints would have forced the issue. There is the DF_WORD_LR code, which tracks the liveness of words in a double-word pseudo. We didn't extend that to variable-length registers for two reasons: (1) if we did need it, we'd want it for pseudos that map to 3 or 4 registers, not just 2, so that LD[234] and ST[234] are handled consistently; and (2) it's only used for DCE at the moment, and it's rare for LD[234]/ST[234]s to be dead code. Thanks, Richard