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 <brooks_at_freebsd.org> 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. RobertReceived on Tue Jun 01 2010 - 14:38:43 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:04 UTC