LLVM IR influence on compiler debugging

[Adam Wilson]

On Sat, 07 Jul 2012 17:04:35 -0700, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Saturday, July 07, 2012 16:54:48 Adam Wilson wrote:
>> On Sat, 07 Jul 2012 16:38:27 -0700, Timon Gehr <timon.gehr at gmx.ch>  
>> wrote:
>> > The DMD backend is very fast in comparison to other backends.
>> >
>> > LLVM is unlikely to catch up in speed, because it is well  
>> architectured
>> > and more general.
>>
>> Oh, I agree that it is, but as I've been saying, raw compiler speed is
>> rarely an important factor outside of small circles of developers, if it
>> was, businesses would have given up on C++ LONG ago. It's nice to have,
>> but the business case for it is weak comparatively.
>
> Just because one set of developers has priorities other than compilation  
> speed
> which they consider to be more important doesn't mean that a lot of  
> developers
> don't think that compilation speed is important. I've worked on projects  
> that
> took over 3 hours to build but that doesn't mean that I wouldn't have  
> wanted
> them to be faster. I've known programmers who complained about builds  
> which
> were over a minute!

Sure they complain, but they would complain harder if the generated code  
was sub-optimal or had bugs in it. And I imagine that multiple hour build  
times are more the exception than rule even in C++, my understanding is  
that all 50mloc of Windows can compile overnight using distributed  
compiling. Essentially, my argument is that for business compilation time  
is something that can be attacked with money, where code generation and  
perf bugs are not.

> If you rate something else higher than compilation speed, that's fine,  
> but that
> doesn't mean that compilation speed doesn't matter, because it does.

That's been my whole point, we need ways to tell other people about the  
pro's and con's of each tool, so that they can choose the right tool,  
knowing it's capabilities and limitations. Right now, it's all DMD.

> And if the various D Compilers are consistent enough, it arguably  
> becomes a
> good course of action to build your ultimate release using gdc or ldc  
> but to
> do most of the direct development on dmd so that you get a fast  
> compile-test-
> rewrite cycle.
>
> - Jonathan M Davis

Except when you are working on architectures that DMD doesn't support.  
Such as Win64, our primary arch here at work. We also want to get into ARM  
on Windows. Win32 is fast becoming irrelevant for new work as almost all  
Win7 machines shipped these days are x64. Essentially, I cannot justify  
DMD under any circumstance for production work here.

However, I realize that for most people Win32 only is just fine. But we  
need a page that explains all these differences. As I said in my first  
post on the subject, I only know the differences because I've been here  
for many months, most decision makers aren't going to dedicate a trivial  
fraction of that time. They'll see that DMD doesn't support Win64 and move  
on without doing the investigation to find out that there is even an  
option for LLVM, because, as near as I can tell, it's not even mentioned.  
They may try GDC only to find that it's not well supported on Windows at  
all (i've heard mixed reports of people getting builds working and it  
seems extremely fragile).

If D is going to use the multiple-tool approach, which I agree it should,  
then we should do our best to promote all the tools and more importantly,  
the community is actively engaged in supporting and improving all of them.  
I am willing to do the website work, but I have no idea when I'll get to  
it as I have other D projects cooking, including GSoC; and more  
importantly, if I even understand the differences well enough myself to  
make accurate statements.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/