From owner-freebsd-arch@FreeBSD.ORG Tue Jun 1 16:38:43 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 841A41065673; Tue, 1 Jun 2010 16:38:43 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5D84F8FC08; Tue, 1 Jun 2010 16:38:43 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 0F3AB46B17; Tue, 1 Jun 2010 12:38:43 -0400 (EDT) Date: Tue, 1 Jun 2010 17:38:42 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Brooks Davis In-Reply-To: <20100601162332.GA35104@lor.one-eyed-alien.net> Message-ID: References: <20100531225732.GF31972@lor.one-eyed-alien.net> <86sk57nmfl.fsf@ds4.des.no> <20100601162332.GA35104@lor.one-eyed-alien.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Dag-Erling Sm??rgrav , current@freebsd.org, arch@freebsd.org Subject: Re: BSDCan Toolchain Summit Summary X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 16:38:43 -0000 On Tue, 1 Jun 2010, Brooks Davis wrote: > On Tue, Jun 01, 2010 at 11:15:26AM +0200, Dag-Erling Sm??rgrav wrote: >> Brooks Davis writes: >>> http://wiki.freebsd.org/201005ToolchainSummitSummary >> >> "No new functionality that requires clang/llvm." >> >> How about "No new functionality with non-trivial incompatibilities with >> clang/llvm"? > > That too. I'll add it to the real roadmap page once I create it. > > As long as people are willing to avoid the darker areas of gcc misfeatures > that shouldn't be a problem in general, but I agree stating it as a target > is a good idea. I think the gist of our discussion was really about where we can/should introduce new dependencies on features specific to clang/llvm. For example, there are some quite interesting ideas about distributing binaries in the LLVM intermediate format and doing on-the-fly tuning for the architecture we find ourselves running on. This is pretty neat stuff, but it does mean that it won't be available in the immediate future for architectures not supported by LLVM or for shops that have to use external non-LLVM-based toolchain parts (such as compilers for specific embedded platforms). I think the consensus from the meeting was that we should start to explore the possible, but that key OS features that don't strictly require new compiler/etc functionality should not be caused to unnecessarily depend on them. This doesn't prohibit doing interesting runtime reoptimization stuff, but it does prohibit making it so that the OS won't work without them. Robert