From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30341 invoked by alias); 13 Sep 2013 11:21:08 -0000 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 Received: (qmail 30331 invoked by uid 89); 13 Sep 2013 11:21:08 -0000 Received: from mail-pd0-f170.google.com (HELO mail-pd0-f170.google.com) (209.85.192.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 13 Sep 2013 11:21:08 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,FREEMAIL_FROM autolearn=ham version=3.3.2 X-HELO: mail-pd0-f170.google.com Received: by mail-pd0-f170.google.com with SMTP id x10so1134436pdj.1 for ; Fri, 13 Sep 2013 04:21:05 -0700 (PDT) X-Received: by 10.68.178.227 with SMTP id db3mr1034299pbc.202.1379071265930; Fri, 13 Sep 2013 04:21:05 -0700 (PDT) Received: from msticlxl57.ims.intel.com (fmdmzpr01-ext.fm.intel.com. [192.55.54.36]) by mx.google.com with ESMTPSA id ct4sm11064028pbb.41.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 13 Sep 2013 04:21:05 -0700 (PDT) Date: Fri, 13 Sep 2013 11:21:00 -0000 From: "Michael V. Zolotukhin" To: Nathan Sidwell Cc: Jakub Jelinek , Kirill Yukhin , Richard Henderson , GCC Development , triegel@redhat.com Subject: Re: [RFC] Offloading Support in libgomp Message-ID: <20130913112035.GB30181@msticlxl57.ims.intel.com> References: <20130823161631.GO1814@tucnak.redhat.com> <20130826115911.GA40923@msticlxl57.ims.intel.com> <20130826125116.GE21876@tucnak.zalov.cz> <20130826132936.GB40923@msticlxl57.ims.intel.com> <20130826141117.GF21876@tucnak.zalov.cz> <20130827112609.GA4093@msticlxl57.ims.intel.com> <20130827113956.GH21876@tucnak.zalov.cz> <20130827115538.GB4093@msticlxl57.ims.intel.com> <20130913093417.GA30181@msticlxl57.ims.intel.com> <5232F12F.6000704@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5232F12F.6000704@acm.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00118.txt.bz2 Hi Nathan, > This is an interesting design. It appears similar to how we'd > envisioned implementing openacc support -- namely leverage the LTO > machinery to communicate from the host compiler to the device > compiler. Your design looks more detailed, which is good. Thanks, do you have a similar description of your design? It would be pretty interesting to take a look at it. > Are you envisioning the device compilers to be stand alone > compilers, built separately. Or are you envisioning extending the > configuration machinery by adding something like > --enable-acclerator= so that: > .../configure --target=x86_64-linux --enable-accelerator=foo,baz > causes > * a build of an x86_64 compiler aware of the foo and baz accelerators > * build of an appropriate runtime support library > * a build of a foo lto accelerator backend, assembler (and linker?) > * (if needed) build of a foo support library > * a build of a baz lto accelerator backend > * (if needed) build of a baz support library, assembler (and linker?) > > or are you expecting something more like 3 separate configures & build? > .../configure --target=x86_64-linux --enable-accelerator=foo,baz > .../configure --target=foo --enable-languages=lto-accelerator > .../configure --target=baz --enable-languages=lto-accelerator > > I'd been imagining the former scheme, as it provides for a more > integrated build, fwiw. That's an open question, and we'd like to clarify it too. We'd appreciate any inputs on this. Personally, I see actually one more option. Similar of how libgomp figures out which runtimes are available (by looking for the corresponding plugins), we could look for available target compilers at compile-time and produce as many target images as number of compilers we have. Thus, we won't need to rebuild host compiler to support more targets - we'd just need to place the corresponding target compiler somewhere. That looks more like your second option, but differs a bit from it in that we don't need to specify enabled accelerators. Michael > nathan