64 bit doubles are sufficient for most applications, but not all.

-Craig

On Mon, 20 Nov 2006 14:37:23 -0800, Gregor Richards <Richards@codu.org> wrote:


>> with  LLVM as he did for gcc.  I wish not because it would be much better if the  reference compiler development could continue on a completely open system.
>>  -JJR
>
> I have now posted this at least three times.
>
> LLVM's compiler is GCC.
>
>   - Gregor Richards

Yes, I've seen your posts. But it's unclear despite the nice little graph that you posted for us to consider.

Quoting the site:

"LLVM is also a collection of source code that implements the language and compilation strategy. The primary components of the LLVM infrastructure are a GCC-based C & C++ front-end, a link-time optimization framework with a growing set of global and interprocedural analyses and transformations, static back-ends for the X86, PowerPC, IA-64, Alpha and SPARC architectures, a back-end which emits portable C code, and a Just-In-Time compiler for X86 and PowerPC processors."

My question is why do they say the the LLVM infrastructure uses the GCC-based /C & C++ front-end/?  The backends are not GCC...  I guess this is just depends how far back the backend is :)?   (Oh wait... GIMPLE is a frontend for the virtual machine)

You mentioned GIMPLE as being used for the IR (Intermediate Representation) which GDC uses to interface with the GCC backend. It's still a little unlcear to me, so have patience.

1) Is GIMPLE a problem for use here? (License-wise)
2) If GIMPLE is the IR, this means that GDC already has all that's necessary to attach to LLVM?
3) Whatever the case, including a GDC front end with LLVM may be easier than doing so with FSF.  FSF seems to want complete ownership of the D frontend before they will accept it into the fold of gcc.  Not sure how the LLVM group will act in this matter, but there licensing method seems quite different.

-JJR

Craig Black wrote:
> 64 bit doubles are sufficient for most applications, but not all.

If the underlying hardware does not support extended real types, then it is reasonable for a D compiler to treat them as doubles. If the hardware does support extended real, then for a D compiler to not support it, well, I'd call that not a proper D implementation.

I've played with LLVM and D, one yr ago, submitting patches to LLVM for VC7 compilation of the LLVM backend, just to try to do a backend for DMD frontend on Windows.

So, as seems that everybody is playing with the frontend, it's not time to have it in a svn repository on DigitalMars/somewhere?
We are all applying the same patches, merging subsequent Walter release, adding headers, and so on...

Can't we work on the same codebase? At least Walter and David Friedman!

Just my 2c....

---
Paolo Invernizzi


Walter Bright wrote:
> John Reimer wrote:
>> I'm wondering if Walter will have the same source "tainting" issue with LLVM as he did for gcc.
> 
> Yes, since it is copyrighted. However, I *can* read documentation about the compiler (one cannot copyright an idea, ideas are covered by patent law, not copyrights).
> 
> Aside from working with the LLVM source, I am happy to help out in any way I can those who want to integrated the D front end with LLVM.
> 
> One advantage LLVM has over gcc is that gcc is reluctant to include gdc as part of the default gcc distribution. If LLVM is willing to include D with their main distribution, that would be very good for D users.