Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Welcome Guest | Log In | Register | Benefits
Channels ▼
RSS

Design

The Design of LLVM



Related Reading


More Insights




The Advent Master

This is an excellent article. I wish this sort of thing had been published to a broader audience and was more readily available when development started on FreeBASIC.

Talk about a compiler with a very specific target domain. However, it still managed to support three compiler dialects and more recently, compilation to C. LLVM has been discussed, but only recently.

Of course, who knows if or when these decisions will ever be acted upon full-throttle. FreeBASIC started out as a successor to QBASIC to try and bring the strangely-still-alive community over to 32-bit systems. As a result, it suffers from poor planning and code structure and lacks features present in nearly all modern programming languages.

I wonder if we'd be better off trying to modify the compiler, rewrite it (doubt it), or extend the language via a sane, modern standard library.

Nawaz

I loved these lines from the article:

>>LLVM's modularity wasn't originally designed to directly achieve any of the goals described here. It was a self-defense mechanism: it was obvious that we wouldn't get everything right on the first try. The modular pass pipeline, for example, exists to make it easier to isolate passes so that they can be discarded after being replaced by better implementations (I often say that none of the subsystems in LLVM are really good until they have been rewritten at least once).

Another major aspect of LLVM remaining nimble (and a controversial topic with clients of the libraries) is our willingness to reconsider previous decisions and make widespread changes to APIs without worrying about backwards compatibility. Invasive changes to LLVM IR itself, for example, require updating all of the optimization passes and cause substantial churn to the C++ APIs. We've done this on several occasions, and though it causes pain for clients, it is the right thing to do to maintain rapid forward progress." <<

That is called fixing issues at the correct end.

I would love to join such a team with this approach. Is there any chance for me to join your team, Chris?

wolverine2k

Thanks for the excellent read! A very good article and I wish every article was this detailed and to the point.

kaustubhb

Have read only the first page yet and I have a feeling I have stumbled on to a gold mine. Kudos for excellent explanation!