From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16575 invoked by alias); 10 Jun 2009 13:00:15 -0000 Received: (qmail 16563 invoked by uid 22791); 10 Jun 2009 13:00:14 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_12,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from mx20.gnu.org (HELO mx20.gnu.org) (199.232.41.8) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Jun 2009 13:00:07 +0000 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MENPR-00060r-7H for gcc@gcc.gnu.org; Wed, 10 Jun 2009 09:00:05 -0400 Received: (qmail 4325 invoked from network); 10 Jun 2009 13:00:04 -0000 Received: from unknown (HELO wren.localnet) (paul@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Jun 2009 13:00:04 -0000 From: Paul Brook To: gcc@gcc.gnu.org Subject: Re: opaque vector types? Date: Wed, 10 Jun 2009 13:00:00 -0000 User-Agent: KMail/1.11.4 (Linux/2.6.29-2-amd64; KDE/4.2.4; x86_64; ; ) Cc: DJ Delorie References: <200905060604.n4664Skm024765@greed.delorie.com> In-Reply-To: <200905060604.n4664Skm024765@greed.delorie.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906101359.59878.paul@codesourcery.com> X-Detected-Operating-System: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-06/txt/msg00236.txt.bz2 On Wednesday 06 May 2009, DJ Delorie wrote: > Is there an opaque vector type? Something that can be assigned > to/from other vector types of the same size, without warning? > > I'm working on a coprocessor which has separate SIMD arithmetic > operations for each data size, but only one SIMD logical operation for > all sizes. I.e. there's four ADD insns (V8QI, V4HI, etc) , but only > one AND insn. I'd like to use an opaque vector type for the AND > builtin, to avoid warnings. FWIW ARM/NEON solve this by defining the full set of builtins for all types, and some of them (e.g. AND) happen to expand to the same machine instructions. In practice I'd expect this actually makes writing vector code easier/safer because you don't loose type safety every time you use the AND builtin. Having some of your intrinsics be type specific, and some type agnostic seems a somewhat strange programming model. I'd expect everything to be types, or everything to use opaque vectors (and select the opcode based on the actual argument types). The latter is problematic because C doesn't really have polymorphism. Paul