From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 7 16:46:00 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0045BC34; Mon, 7 Jan 2013 16:45:59 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id BFC7C6EA; Mon, 7 Jan 2013 16:45:59 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MG900G02L7Z7X00@smtpauth2.wiscmail.wisc.edu>; Mon, 07 Jan 2013 10:45:35 -0600 (CST) Received: from wanderer.tachypleus.net (216-75-226-134.static.wiline.com [216.75.226.134]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MG900BB1L7WDD30@smtpauth2.wiscmail.wisc.edu>; Mon, 07 Jan 2013 10:45:33 -0600 (CST) Date: Mon, 07 Jan 2013 08:45:32 -0800 From: Nathan Whitehorn Subject: Re: LLVM Image Activator In-reply-to: <201301071825.06439.naylor.b.david@gmail.com> Sender: whitehorn@wisc.edu To: David Naylor Message-id: <50EAFBAC.2020808@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=216.75.226.134 X-Spam-PmxInfo: Server=avs-14, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.7.163317, SenderIP=216.75.226.134 References: <50E9BC2D.7000302@freebsd.org> <201301071825.06439.naylor.b.david@gmail.com> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 Cc: freebsd-toolchain@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 16:46:00 -0000 On 01/07/13 08:25, David Naylor wrote: > Hi, > > Just my 2c > > On Sunday, 6 January 2013 20:02:21 Nathan Whitehorn wrote: >> Having LLVM/clang in the base system lets us do some interesting things >> that we couldn't do with GCC. One is that LLVM ships with a JIT for LLVM >> IR as well as components of a toolchain for it (this is what Google's >> pNACL uses) and that you can end up producing binary files that are in >> IR instead of native code. The IR isn't really cross-platform, but does >> let you do CPU-specific optimizations when executed by the JIT, etc. >> >> The attached patch causes the LLVM JIT (lli) to be built by default >> (adding ~20 seconds to buildworld on my five-year-old laptop) and adds a >> kernel image activator that invokes it when passed LLVM bitcode files. >> It's not completely finished (see the XXX comment in the middle), but it >> does work, as follows: >> >> $ clang -emit-llvm -c -o hw.ll hw.c >> $ file hw.ll >> hw.ll: LLVM bitcode >> $ lli hw.ll >> Hello world! >> $ chmod a+x hw.ll >> $ ./hw.ll >> Hello world! >> $ >> >> Is there any interest in having features like this? It seems like this >> could provides some interesting possibilities for us and nice >> integration from having imported clang into base. > > Would it be possible to have this as a module (and thus in ports)? Or, > perhaps, change the sources such these things could be loaded as a module... We do support that, but I'm not really sure what would be gained. We have LLVM in base; it seems a shame not to use it. > Also, with modification to LLVM, wouldn't the existing '#!' mechanism work > (aka '#!/usr/bin/lli') at the beginning of the file? In principle, yes, but we'd have to coordinate that with a lot of players since a number of tools operate on LLVM bitcode. The other obstacle is that LLVM bitcode is a giant binary blob, not text, so the standard #! seems a little out of place. > On an aside. Could you imagine shipping a 'x86' llvm-byte code and get the > jit (with caching), thus your computer will get full support (speed) from the > binaries and the binaries will work on all 'x86' related architectures. (My > thinking is for things like i386 vs pentium4). > Yes, this is exactly the kind of thing I had in mind. -Nathan