Monday, July 9, 2012

Embarcadero - Clang and LLVM

Recently Tim Anderson reported that Embarcadero was going to be using the Clang Compiler in the Rad Studio.   When word broke about Embarcadero using LLVM with Delphi I was quite pleased.   I had been playing around with LLVM learning its IR for quite some time and it is a great tool for most any development language.    However, knowing that they have based there C++ work on the the Clang Compiler is very pleasing to me.    Clang is a very nice C/C++/Objective-C Compiler.

Benefits of the Clang Compiler  
Some of the Benefits of LLVM (I really don't do it justice with my small list)
All of this makes me wonder how much of other things from LLVM that they may end up using all or part of  as  LLDB, KLEE, or VMKit

Now which features of clang and llvm will be exposed in the Embarcadero tool chain is not know yet.   But it's nice to know that there is a good foundation they are building on.    

I guess it might be time to sign up for Priority Preview Access to see this in action.


  1. It seems that next Delphi version won't be based on LLVM but only C++, You can understand it by their last roadmap, which states Android support for C++ (not mentioning Delphi ), it means it takes some time to build a Delphi front end for LLVM.

    1. I have wondered that as well, but some part of Delphi will need to be done as Firemonkey is written in Delphi and that is on the roadmap.

    2. When the Front End for the Delphi is created and Released, it will definitely loose its "World's Fastest Compiler" title, but definitely get more features.. !! Sorry if i am wrong , I don't know much about LLVM's Compilation speed.

    3. You can easely test it on any Mac with XCode 4.3+, due to LLVM to be default compiler for XCode from that version. Perfomance is good for most cases on average iMac. I can mention that xcode is free))

      One note: frontend for Delphi is not that hard task as you can probably guess. RAD Studio already have 2 parsers for Delphi (ide-internal and in-compiler), so all you need is to adopt this parser to produce llvm compatible output. Of course, i mean "not hard" for company able to make some compiler themselfs, not mere mortals))

  2. Delphi compiler is an one-pass compiler. How about LLVM?

    1. I don't know if the current Delphi is a one pass compiler or not.
      Granted the language design is that it could be a single pass. But that does not mean that the current compiler is one pass.

      Regardless, you will need multiple passes to implement LLVM, as the front end will generate LLVM IR, which is then used for the backend operations.

      LLVM will run several passes for optimization, for backend code gen.

      I suspect this will cause speed concerns for some developers, but I would caution that performance can not be something you guess at it needs to be measured. Also performance is far more than just passes, many other things effect performance like Memory & IO usage, AST tree design/size, ability to use multiple cores, etc...

      I believe that multiple platform targets is far easier to implement, maintain and enhance when you have a Target Independent IR. Having that means that you will have multiple passes.

  3. Clang compiles faster than GCC, but its code AFAIK is a little slower. But compared to VC++ and Intel? I really don't care about GCC, because my target platform is Windows.
    And is it faster than Delphi?

    Anyway Embarcadero is telling us they don't have the R&D to develop a compiler any longer. Not good news, whatever compiler the choose to rely upon. They sell expensive devtools, and can't write a compiler.

    The fact that Apple uses it doesn't mean anything. Apple is not a development tools company. It's an hardware company. Whatever is good enough to sustain its hardware sales is ok. But Embarcadero is a development tool company. If they can't develop the foundation of any development tool, what's the quality of the remaining parts? Remember what happened to JBuilder that relied on javac...

    1. As I said above but in different terms. Speed (compile time or execution time) can not be guessed, it must be measured. There is no Delphi compiler that uses LLVM that can be compared to the current Delphi Compiler. Spreading worries about this before a product is released is only FUD talking it's not facts.

      Using LLVM is not saying they don't have the R&D to build a compiler. Delphi will still need a compiler that Embarcadero builds. Clang on the other hand may say that , they don't want to invest as much money in R&D on the C++ compiler. But having a compiler that more compatible with other C/C++ compilers is more important to me than having them build the compiler internally. Also have the extra R&D resources that could be directed towards Delphi compiler could be nice.

      Having done enough work with LLVM I would consider it a good move for most any company to consider it as a back end. Especially if you intend to target multiple platforms. It is used by a wide assortment of companies. Including Intel, and Nvida... However, they are hardware companies so they the must not count. Hardware companies don't care about the performance

      What I care about as a Embarcadero Customer when it comes to the compiler is:

      1. It works, quality is more important than anything as I can't fix the compiler like I can fix other things.

      2. I don't loose functionality that I depend on without a compelling reason for me change my code.

      3. Fast Execution Time
      My application performance can not drop.

      4.Fast enough Compile Times, I am willing to wait a few seconds longer on 30 minute build script. (I have many projects in my build script) I don't want to wait several minutes longer but I am not worried about a few seconds in over all build time.

      5. Can target the platforms I need to deploy too.

      I don't care if it's 100% build in house or they use other tools to help out, all I care about is the finished product. Having said that I believe that LLVM will help the finished product be better. I base that on my experience using LLVM.

    2. I was talking about C++ performance. I would like to see comparison of Clang code performance against VC++ and Intel (which uses Clang only for its OpenCL product), not only against GCC which is not the mainstream Windows compiler.
      Using LLVM *is* saying they don't have R&D to build a compiler, especially if you move the Delphi compiler to LLVM too. Once Borland could challenge Microsoft in C++ compilers, now it has to look for someone's else compiler. Sure, they save money, but the meaning of this move is clear. It is true you can get a good compiler, but you'll never able to get a better one (not that Embarcadero was able to do it for a long time, thereby users are now satisfied to get less as long as it works...)
      Also I would like to understand how they could use LLVM with Delphi, because the Delphi compiler and linker doesn't output plain C/C++ files but uses its own formats to support its features. How much are they going to change?
      And as a customer I *do* care is they start to sell me code they get for free at $2500...

    3. Why not. It does not matter who develops the compiler. As long as the solution works.

      Exactly what you, Luigi, mentioned is the point. MS C/C++ compiler is the best compromise on Windows. Open Source people will not use anything but what they already have. GCC is UNIX. Of course a home made compiler is missing, but I think the chance for acceptance would not be very high at the moment. Why not benefit form things provided by the Open Source community. The work left for all the other parts of FMX and C++ Builder is enough. Maybe the world requires a C/C++ compiler by EMB one day ... I am sure not this fall and not the next:) Maybe it is simpler for EMB to exchange the GCC part but rely on the LLVM integration. Whatever will come, we will see.

      Anyway –

    4. I have no problem with USD 2500 in general. If we start paying EMB for integrating more and more sophisticated stuff into an IDE that becomes more and more complex - World championship in building potentially fragile but working things - then no price will help. People choose the simpler option. Until today I did not see such a movement.

      The C/C++ people in general are purists and strong focusing on keeping everything separated - no dependency between IDE, compiler and framework. If someone wants RAD and C++ and can live with the dependency and most of us can - why not.

    5. Luigi: It's clear you don't understand how LLVM works.

      The Delphi compiler built using LLVM, would not require C/C++ output to work. It would require output of LLVM IR.

    6. Sure, they write the Delphi Pascal code generator that outputs IR. But then they have to enter the whole LLVM stack if they want to use LLVM. How it maps to the compiler/linker stack used today by Delphi, with its uses, dcu and interface/implementation way of resolving identifiers? Are they going to mantain it? Are they going to change it? How many tools now working with Delphi (i.e. profilers) will stop working?

    7. @LDS, sure those problems are there when implementing Delphi for LLVM, but I think they have(or Had) the same problem when implementing LLVM C++ builder with the RAD IDE

  4. I don't care if it's 100% build in house or they use other tools to help out, all I care about is the finished product.

    Still some of the M$ products are not made in house , but bought form third party(eg: skype, some part of bing , Microsoft games etc.. )but it doesn't mean that they are incapable of developing software.

  5. I think LLVM is good idea. It's good compiler and can give Delphi many optimizations it never had. For me it's not problem at all that Embarcadero will use opensource project as I don't have to wait few years to have deep-optimized compiler.

    I suppose compilation speed shouldn't suffer a lot, at least in DEBUG mode. RELEASE mode can be a bit slower.

    Anyway I'm excited and waiting when Delphi frontend for LLVM will be done, and all IDE and internal stuff tweaked. I'm really curious and willing to test new codegenerator.

  6. let's wait and see ...

    ps: me self don't care if it's 100% build in house or not.