public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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
Date: Fri, 28 Mar 2003 00:03:00 -0000	[thread overview]
Message-ID: <20030327232140.GB22572@kam.mff.cuni.cz> (raw)
In-Reply-To: <80BD18BC-6099-11D7-BCCF-000393750C1E@redhat.com>

> 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

  reply	other threads:[~2003-03-27 23:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-27 23:04 Aldy Hernandez
2003-03-28  0:03 ` Jan Hubicka [this message]
2003-03-31 20:03   ` Aldy Hernandez
2003-04-01 15:46     ` Jan Hubicka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030327232140.GB22572@kam.mff.cuni.cz \
    --to=jh@suse.cz \
    --cc=aldyh@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=rth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).