From: Kenneth Zadeck <zadeck@naturalbridge.com>
To: Mike Stump <mikestump@comcast.net>
Cc: Richard Guenther <richard.guenther@gmail.com>,
"H.J. Lu" <hjl.tools@gmail.com>,
"H.J. Lu" <hongjiu.lu@intel.com>,
gcc-patches Patches <gcc-patches@gcc.gnu.org>
Subject: Re: RFC: PATCH: Remove 26 element limit in vector
Date: Thu, 31 Mar 2011 12:14:00 -0000 [thread overview]
Message-ID: <4D946E25.4070503@naturalbridge.com> (raw)
In-Reply-To: <D2A15903-206A-44C4-AC4E-7B64BED5F927@comcast.net>
we hit this limit trying to write the explicit semantics for a
vec_interleave_evenv32qi.
;;(define_insn "vec_interleave_evenv32qi"
;; [(set (match_operand:V32QI 0 "register_operand" "=r")
;; (vec_select:V32QI
;; (vec_concat:V64QI
;; (match_operand:V32QI 1 "register_operand" "0")
;; (match_operand:V32QI 2 "register_operand" "r"))
;; (parallel [(const_int 0) (const_int 32)
;; (const_int 2) (const_int 34)
;; (const_int 4) (const_int 36)
;; (const_int 6) (const_int 38)
;; (const_int 8) (const_int 40)
;; (const_int 10) (const_int 42)
;; (const_int 12) (const_int 44)
;; (const_int 14) (const_int 46)
;; (const_int 16) (const_int 48)
;; (const_int 18) (const_int 50)
;; (const_int 20) (const_int 52)
;; (const_int 22) (const_int 54)
;; (const_int 24) (const_int 56)
;; (const_int 26) (const_int 58)
;; (const_int 28) (const_int 60)
;; (const_int 30) (const_int 62)])))]
;; ""
;; "rimihv\t%0,%2,8,15,8"
;; [(set_attr "type" "rimi")])
kenny
On 03/31/2011 06:16 AM, Mike Stump wrote:
> On Mar 31, 2011, at 1:41 AM, Richard Guenther wrote:
>> On Wed, Mar 30, 2011 at 8:09 PM, H.J. Lu<hongjiu.lu@intel.com> wrote:
>>> On Wed, Mar 30, 2011 at 08:02:38AM -0700, H.J. Lu wrote:
>>>> Hi,
>>>>
>>>> Currently, we limit XVECEXP to 26 elements in machine description
>>>> since we use letters 'a' to 'z' to encode them. I don't see any
>>>> reason why we can't go beyond 'z'. This patch removes this restriction.
>>>> Any comments?
>>>>
>>> That was wrong. The problem is in vector elements. This patch passes
>>> bootstrap. Any comments?
>> Do you really need it?
> I'm trying to recall if this is the limit Kenny and I hit.... If so, annoying. Kenny could confirm if it was. gcc's general strategy of, no fixed N gives gcc a certain flexibility that is very nice to have, on those general grounds, I kinda liked this patch.
next prev parent reply other threads:[~2011-03-31 12:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-30 15:05 RFC: PATCH: Remove 26 element limit in XVECEXP H.J. Lu
2011-03-30 18:55 ` RFC: PATCH: Remove 26 element limit in vector H.J. Lu
2011-03-31 8:47 ` Richard Guenther
2011-03-31 9:58 ` Richard Sandiford
2011-03-31 10:20 ` Mike Stump
2011-03-31 12:14 ` Kenneth Zadeck [this message]
2011-04-05 1:05 ` H.J. Lu
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=4D946E25.4070503@naturalbridge.com \
--to=zadeck@naturalbridge.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hjl.tools@gmail.com \
--cc=hongjiu.lu@intel.com \
--cc=mikestump@comcast.net \
--cc=richard.guenther@gmail.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).