From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-121858-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 675 invoked by alias); 17 Nov 2005 16:25:42 -0000
Received: (qmail 608 invoked by uid 22791); 17 Nov 2005 16:25:39 -0000
Received: from commerce-02.cilia.org (HELO commerce-02.cilia.org) (65.174.6.30)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 17 Nov 2005 16:25:38 +0000
Received: from zadeck.dynalias.net (pool-71-251-7-110.nycmny.fios.verizon.net [71.251.7.110])
	by commerce-02.cilia.org (Postfix) with ESMTP id 50BA639DA9;
	Thu, 17 Nov 2005 11:25:17 -0500 (EST)
Received: from numenor.site (localhost [127.0.0.1])
	by zadeck.dynalias.net (Postfix) with ESMTP id 3D72E74649;
	Thu, 17 Nov 2005 11:25:15 -0500 (EST)
From: Kenneth Zadeck <Kenneth.Zadeck@NaturalBridge.com>
To: Ian Lance Taylor <ian@airs.com>
Cc: gcc mailing list <gcc@gcc.gnu.org>
Subject: Re: Link-time optimzation
Reply-To: Kenneth.Zadeck@NaturalBridge.com
In-Reply-To: <0cc801c5eb55$e902a7a0$264e2697@bagio>
Message-Id: <20051117162515.3D72E74649@zadeck.dynalias.net>
Date: Thu, 17 Nov 2005 16:25:00 -0000
X-Cilia-MailScanner-Information: Please contact the ISP for more information
X-Cilia-MailScanner: Found to be clean
X-Cilia-MailScanner-From: kenneth.zadeck@naturalbridge.com
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2005-11/txt/msg00781.txt.bz2

> >> Thanks for woking on this. Any specific reason why using the LLVM
> >> bytecode wasn't taken into account?
> >
> > It was.
> > A large number of alternatives were explored, including CIL, the JVM,
> > LLVM, etc.
> >
> >> It is proven to be stable, high-level enough to
> >> perform any kind of needed optimization,
> >
> > This is not true, unfortunately.
> > That's why it is called "low level virtual machine".
> > It doesn't have things we'd like to do high level optimizations on,
> > like dynamic_cast removal, etc.
> 
> 
> Anyway, *slightly* extending an existing VM which already exists, is
> production-ready, is GPL compatible, is supported by a full toolchain
> (including interpreters, disassemblers, jitters, loaders, optimizers...) looks
> like a much better deal. Also, I'm sure Chris would be willing to provide us
> with all the needed help.
> 
> I also think CIL would have egregiously worked. I'm sure the reasons to refuse
> it are more political than tecnical, so it's useless to go into further details
> I presume.

I do not think that CIL really would have worked.  CIL has been
carefully crafted to support what Microsoft wants it to support and
unrestricted C, C++, and Fortran are not in that mix.  

Remember that Microsoft wants to be able to take a CIL program
produced on one (?Microsoft?) platform and run it on another
(?Microsoft?) platform.  By the time we get to where we want to
produce the iterchangable code, the il has a lot of platform knowledge
(for instance generated by the C preprocessor) that cannot be easily
accounted for.


> 
> Giovanni Bajo