From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19833 invoked by alias); 8 Jun 2009 20:33:12 -0000 Received: (qmail 19823 invoked by uid 22791); 8 Jun 2009 20:33:12 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_42 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 08 Jun 2009 20:33:07 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 4C56910F6B; Mon, 8 Jun 2009 20:33:05 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 2D00E10F6A; Mon, 8 Jun 2009 20:33:05 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1MDlWi-0002DR-67; Mon, 08 Jun 2009 16:33:04 -0400 Date: Mon, 08 Jun 2009 20:33:00 -0000 From: Daniel Jacobowitz To: Jakub Jelinek Cc: "Joseph S. Myers" , Nathan Froyd , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] fix arm neon ICE by widening tree_type's precision field Message-ID: <20090608203304.GA7987@caradoc.them.org> Mail-Followup-To: Jakub Jelinek , "Joseph S. Myers" , Nathan Froyd , gcc-patches@gcc.gnu.org References: <20090608153204.GW21107@codesourcery.com> <20090608195211.GA3684@caradoc.them.org> <20090608201817.GK4822@tyan-ft48-01.lab.bos.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090608201817.GK4822@tyan-ft48-01.lab.bos.redhat.com> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes 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 X-SW-Source: 2009-06/txt/msg00698.txt.bz2 On Mon, Jun 08, 2009 at 10:18:17PM +0200, Jakub Jelinek wrote: > On Mon, Jun 08, 2009 at 03:52:11PM -0400, Daniel Jacobowitz wrote: > > In order to get good code out of these, I think we'd need to represent > > early on that the single gimple operation set three different vectors > > (SSA? What SSA?) Also we'd need to somehow do sensible register > > allocation for these constraints. > > > > Instead, we do not support these in the vectorizer; use unions for > > the intrinsics (which do not get scalarized, so perhaps the new SRA > > will help here), and fake it with these huge partial modes during RTL > > expansion. See the XImode patterns in neon.md for examples. > > > > Any ideas? :-) > > Why do you need the big modes? If the insn does load from memory into > a couple of registers (or stores from couple of registers into memory), > why can't you just use a parallel with all those stores in it? > See e.g. s390.md for load_multiple and store_multiple... Two reasons. One, for the intrinsics, which use __builtin_neon_xi and so forth. The other, for the register allocation constraints. I don't see any way we could tell the register allocator "these three operands must have consecutive register numbers" (or, even worse, consecutive with stride 2). S/390 handles this by generating load_multiple directly for hard registers, only if reload_completed. -- Daniel Jacobowitz CodeSourcery