From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-71103-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 7302 invoked by alias); 27 Mar 2003 23:21:36 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 7295 invoked from network); 27 Mar 2003 23:21:36 -0000
Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106)
  by sources.redhat.com with SMTP; 27 Mar 2003 23:21:36 -0000
Received: from camelot.ms.mff.cuni.cz (kampanus.ms.mff.cuni.cz [195.113.18.107])
	by nikam.ms.mff.cuni.cz (Postfix) with SMTP
	id BACE24DE31; Fri, 28 Mar 2003 00:21:37 +0100 (CET)
Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Fri, 28 Mar 2003 00:21:40 +0100
Date: Fri, 28 Mar 2003 00:03:00 -0000
From: Jan Hubicka <jh@suse.cz>
To: Aldy Hernandez <aldyh@redhat.com>
Cc: GCC Mailinglist <gcc@gcc.gnu.org>, Jan Hubicka <jh@suse.cz>,
	Richard Henderson <rth@redhat.com>
Subject: Re: RFC: new rtl vec_set_unit/vec_get_unit
Message-ID: <20030327232140.GB22572@kam.mff.cuni.cz>
References: <80BD18BC-6099-11D7-BCCF-000393750C1E@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <80BD18BC-6099-11D7-BCCF-000393750C1E@redhat.com>
User-Agent: Mutt/1.3.28i
X-SW-Source: 2003-03/txt/msg01686.txt.bz2

> I can't seem to find the original thread on the GCC archive, but... 
> there was a discussion a while back between Jan, Richard, and me about 
> subregs of SIMD types creating bogus code.
> 
> Particularly, when we have a hard register, both of the following 
> snippets end up referencing r0 because we have no way of distinguishing 
> the upper and the lower halves:
> 
> 	(set (subreg:SI (reg:V2SI r0) 0) (reg:SI xx))
> 	(set (subreg:SI (reg:V2SI r0) 4) (reg:SI xx))
> 
> It was suggested that we add new RTL code to deal with this, but the 
> exact semantics had not been proposed.  I'm taking this up again, and 
> here is the proposed syntax:
> 
> 	(vec_set_unit:SI (reg:V2SI r9) 1 (reg:SI r5))
> 
> and
> 
> 	(set (reg:SI r88) (vec_get_unit:SI (reg:V2SI r9) 1))
> 
> Then, the expanders:
> 
> (define_expand "vec_set_unitv2si"
> 	(set (match_operand:V2SI 0)
> 	     (vec_set_unit:V2SI (match_operand:V2SI 1)
> 				(match_operand 2 immediate)
> 				(match_operand:SI 3)))
> 
> and...
> 
> (define_expand "vec_get_unitv2si"
>   [(set (match_operand:SI 0)
> 	    (vec_get_unit:SI (match_operand:V2SI 1)
> 						 (match_operand:SI 2)))]
> 
> I think it's all pretty clear.  If no one objects as to the syntax, 
> I'll start hacking away.

This is still something I would like to look into.  The expanders to
get/set pariticular fields of the vector looks like obvious sollution.
However the problem is that the code generated for SSE would be ugly,
especially when taking into account V16QImode where to access paritcular
mode number of rotations on different temporaries needs to be made.

Most of the time we need to get/set all the fields of vector at once (to
simulate vector operation) so perhaps we should have both.
We probably need both mechanizms as in some cases it is deifnitly
desirable to access particular fields of the vector.

Also vec_set_unit/vec_get_unit can be expanded into
vec_select/vec_duplicate operations so there is probably no need to
invent the RTL construct for that, we only need the named patterns.

Honza
> 
> Aldy