From patchwork Fri Sep 13 03:07:20 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Modra X-Patchwork-Id: 274635 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 4AFB62C0134 for ; Fri, 13 Sep 2013 13:07:39 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=wlPOKBKRPIo8WE/9B 3naIEp4IkY3ySdSBQAsUazacra0FtjUSPdJGlIPiF5FH44w1q9IalLApEaLKVzTv Xij7ev3iR4RnYjVJWmPXvQYUkCJGq5PbhSyB+JgrsGvDBBb7TYOLDtv44k+k5Obv D3AxgjjhM7pVX2wTLEd64qC2oo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=default; bh=YXjos10m5nnwF4VlUYs/UCE RoTY=; b=AliFOze/4Y1IMsimCaVm1gHsIa4wfUz+i+6BrH0Ifmp6+fgaG6PZbMX 4y2hFtz0Ex1S7NJFxEdZbO45AL2W0dY2DThttGO6gi6q9K1WUcwsbwkoTtn6rFHv iI25KekgFrSt8kgpPG8PwghU6NsyJjXBSACfMSIqNMcgucbET1Ec= Received: (qmail 6119 invoked by alias); 13 Sep 2013 03:07:30 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 6103 invoked by uid 89); 13 Sep 2013 03:07:29 -0000 Received: from mail-pa0-f51.google.com (HELO mail-pa0-f51.google.com) (209.85.220.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 13 Sep 2013 03:07:29 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00, FREEMAIL_FROM autolearn=ham version=3.3.2 X-HELO: mail-pa0-f51.google.com Received: by mail-pa0-f51.google.com with SMTP id lf1so1938580pab.24 for ; Thu, 12 Sep 2013 20:07:26 -0700 (PDT) X-Received: by 10.69.12.36 with SMTP id en4mr10976966pbd.54.1379041645892; Thu, 12 Sep 2013 20:07:25 -0700 (PDT) Received: from bubble.grove.modra.org ([101.166.26.37]) by mx.google.com with ESMTPSA id qp10sm14502673pab.13.1969.12.31.16.00.00 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 20:07:25 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id D0BC2EA0077; Fri, 13 Sep 2013 12:37:20 +0930 (CST) Date: Fri, 13 Sep 2013 12:37:20 +0930 From: Alan Modra To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: Re: expand_expr tweaks to fix PR57134 Message-ID: <20130913030720.GC22902@bubble.grove.modra.org> Mail-Followup-To: Richard Biener , gcc-patches@gcc.gnu.org References: <20130612024834.GY6878@bubble.grove.modra.org> <20130614083832.GK21523@bubble.grove.modra.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes This is a followup to http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00837.html which is still lacking an OK. Apologies for dropping this patch on the floor. PR middle-end/57586 * stmt.c (expand_asm_operands): Call expand_expr with EXPAND_MEMORY for output operands that disallow regs. Don't use EXPAND_WRITE on inout operands. On Fri, Jun 14, 2013 at 11:38:58AM +0200, Richard Biener wrote: > On Fri, Jun 14, 2013 at 10:38 AM, Alan Modra wrote: > > On Thu, Jun 13, 2013 at 10:45:38AM +0200, Richard Biener wrote: > >> On Wed, Jun 12, 2013 at 4:48 AM, Alan Modra wrote: > >> > The following patch fixes PR57134 by > >> > a) excluding bitfield expansion when EXPAND_MEMORY, and > >> > b) passing down the EXPAND_MEMORY modifier in a couple of places where > >> > this does not currently happen on recursive calls to expand_expr(). > >> > >> I suppose it also fixes PR57586 which looks similar? > > > > Not completely. It cures the ICE, but you still get "output number 0 > > not directly addressable". The reason being that expand_asm_operands > > isn't asking for a mem. It should I guess, and also not specify > > EXPAND_WRITE on an inout parameter. Bootstrapped and regression > > tested powerpc64-linux. > > It looks reasonable to me, but I'm not too familiar with EXPAND_MEMORY > vs. EXPAND_WRITE. For the expr.h comment "EXPAND_WRITE means we are only going to write to the resulting rtx." So fairly obviously we shouldn't use that with inout asm args. > Btw, I wonder if for strict-alignment targets asm()s can expect "aligned" > memory if they request an asm input with "m"? Thus, do we eventually > have to copy a known unaligned mem to aligned scratch memory before > passing it to a "m" input? Do we maybe have to do the same even for > "m" outputs? Or is this all simply undefined and asm()s have to handle > arbitrary alignment of memory operands (well, those that appear > at runtime, of course). I'm sure the kernel people would rather *not* have copies to scratch memory. The testcase in pr57586 was derived from kernel code that munges pointers. A testcase that better shows what is going on, probably from the same kernel code, is here http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134#c3 (The pointer munging is what causes gcc to lose track of alignment.) Index: gcc/stmt.c =================================================================== --- gcc/stmt.c (revision 202428) +++ gcc/stmt.c (working copy) @@ -806,7 +806,10 @@ expand_asm_operands (tree string, tree outputs, tr || ! allows_reg || is_inout) { - op = expand_expr (val, NULL_RTX, VOIDmode, EXPAND_WRITE); + op = expand_expr (val, NULL_RTX, VOIDmode, + !allows_reg ? EXPAND_MEMORY + : !is_inout ? EXPAND_WRITE + : EXPAND_NORMAL); if (MEM_P (op)) op = validize_mem (op);