From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23888 invoked by alias); 12 Nov 2014 12:34:33 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 23877 invoked by uid 89); 12 Nov 2014 12:34:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f174.google.com Received: from mail-ob0-f174.google.com (HELO mail-ob0-f174.google.com) (209.85.214.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 12 Nov 2014 12:34:31 +0000 Received: by mail-ob0-f174.google.com with SMTP id uz6so8911857obc.5 for ; Wed, 12 Nov 2014 04:34:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.174.206 with SMTP id x197mr1487603oie.78.1415795669783; Wed, 12 Nov 2014 04:34:29 -0800 (PST) Received: by 10.76.101.132 with HTTP; Wed, 12 Nov 2014 04:34:29 -0800 (PST) In-Reply-To: <54451994.9070209@codesourcery.com> References: <54451994.9070209@codesourcery.com> Date: Wed, 12 Nov 2014 12:36:00 -0000 Message-ID: Subject: Re: The nvptx port [0/11+] From: Richard Biener To: Bernd Schmidt , David Edelsohn Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg01189.txt.bz2 On Mon, Oct 20, 2014 at 4:17 PM, Bernd Schmidt wrote: > This is a patch kit that adds the nvptx port to gcc. It contains preliminary > patches to add needed functionality, the target files, and one somewhat > optional patch with additional target tools. There'll be more patch series, > one for the testsuite, and one to make the offload functionality work with > this port. Also required are the previous four rtl patches, two of which > weren't entirely approved yet. > > For the moment, I've stripped out all the address space support that got > bogged down in review by brokenness in our representation of address spaces. > The ptx address spaces are of course still defined and used inside the > backend. > > Ptx really isn't a usual target - it is a virtual target which is then > translated by another compiler (ptxas) to the final code that runs on the > GPU. There are many restrictions, some imposed by the GPU hardware, and some > by the fact that not everything you'd want can be represented in ptx. Here > are some of the highlights: > * Everything is typed - variables, functions, registers. This can > cause problems with K&R style C or anything else that doesn't > have a proper type internally. > * Declarations are needed, even for undefined variables. > * Can't emit initializers referring to their variable's address since > you can't write forward declarations for variables. > * Variables can be declared only as scalars or arrays, not > structures. Initializers must be in the variable's declared type, > which requires some code in the backend, and it means that packed > pointer values are not representable. > * Since it's a virtual target, we skip register allocation - no good > can probably come from doing that twice. This means asm statements > aren't fixed up and will fail if they use matching constraints. > * No support for indirect jumps, label values, nonlocal gotos. > * No alloca - ptx defines it, but it's not implemented. > * No trampolines. > * No debugging (at all, for now - we may add line number directives). > * Limited C library support - I have a hacked up copy of newlib > that provides a reasonable subset. > * malloc and free are defined by ptx (these appear to be > undocumented), but there isn't a realloc. I have one patch for > Fortran to use a malloc/memcpy helper function in cases where we > know the old size. > > All in all, this is not intended to be used as a C (or any other source > language) compiler. I've gone through a lot of effort to make it work > reasonably well, but only in order to get sufficient test coverage from the > testsuites. The intended use for this is only to build it as an offload > compiler, and use it through OpenACC by way of lto1. That leaves the > question of how we should document it - does it need the usual constraint > and option documentation, given that user's aren't expected to use any of > it? > > A slightly earlier version of the entire patch kit was bootstrapped and > tested on x86_64-linux. Ok for trunk? Now that this has been committed - I notice that there is no entry in MAINTAINERS for the port. I propose Bernd. Thanks, Richard. > > Bernd