From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3408 invoked by alias); 13 Feb 2011 15:38:09 -0000 Received: (qmail 3398 invoked by uid 22791); 13 Feb 2011 15:38:08 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 13 Feb 2011 15:38:03 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id p1DFbwoX010546; Sun, 13 Feb 2011 16:37:59 +0100 (CET) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id p1DFbvf2004634; Sun, 13 Feb 2011 16:37:57 +0100 (CET) Date: Sun, 13 Feb 2011 15:38:00 -0000 Message-Id: <201102131537.p1DFbvf2004634@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: uweigand@de.ibm.com CC: gdb-patches@sourceware.org In-reply-to: <201102021748.p12Hm18H010975@d06av02.portsmouth.uk.ibm.com> (uweigand@de.ibm.com) Subject: Re: [rfc] Implement support for IBM XL C for OpenCL vector ABI References: <201102021748.p12Hm18H010975@d06av02.portsmouth.uk.ibm.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00248.txt.bz2 > Date: Wed, 2 Feb 2011 18:48:00 +0100 (CET) > From: "Ulrich Weigand" > > Hello, > > code generated for OpenCL C kernels does not necessarily need to > adhere to a platform-defined ABI, since OpenCL does not allow to > link binary components together. However, since GDB allows for > inferior function calls to routines defined as part of an OpenCL > C kernel, it needs to understand the de-facto ABI used on any > given implementation. > > With the IBM XL C for OpenCL compiler, we mostly use the existing > platform ABI for the PowerPC and SPU architectures. However, the > OpenCL C language defines a large set of vector types that do not > correspond to any of the pre-existing data types. For those, the > compiler chose to implement an ABI. GDB's current implementation > does not always match this ABI. > > The following patch implements support for the actually implemented > ABI in OpenCL C for PowerPC and SPU. To do so, we need to actually > know whether any given function uses the OpenCL C ABI (as opposed > to the regular platform ABI). Ideally, we'd want to know if the > inferior function to be called originates in an OpenCL C source > file compiled with the IBM XL compiler, but this information is > no longer directly available in the push_dummy_call etc. callbacks. > > What *is* available is the TYPE_CALLING_CONVENTION attribute. However, > this is determined from DWARF DW_AT_calling_convention attributes, > which the OpenCL compiler does not actually set. To work around this, > the patch below hard-codes a special flag to be used as value of > TYPE_CALLING_CONVENTION, which is set depending on the compiler > that built the source file (i.e. DWARF "producer"). > > This extra flag is defined by GDB itself, and has a value outside > the defined range of DW_AT_calling_convention attribute values, > so there should be no potential conflict. > > Does this look reasonable? If anyone sees a better way to implement > this, I'd appreciate any suggestions ... > > Using this value, the patch below then implements the OpenCL ABI > for both PowerPC (32-bit and 64-bit) and SPU, both for function > calls and function return. > > Tested on powerpc64-linux and Cell/B.E. using the IBM XL C for > OpenCL compiler and OpenCL runtime. > > Note that this patch assumes the PowerPC AltiVec ABI fix here: > http://sourceware.org/ml/gdb-patches/2011-02/msg00021.html > is already applied. > > Any comments welcome! I'm planning on committing this in a > week or so. I didn't look too closely at the diff yet, but given that push_dummy_call() functions tend to be fairly complex already, would it be possible to move the OpenCL calling convention into a seperate function?