Hacker News Reader

Comment by pcwalton | Hacker News Reader

Don't compile to C. It's very difficult to avoid undefined behavior, you won't be able to modify the compiler backend (and you will want to as you start optimizing), you can't add new language intrinsics, good GC is pretty much incompatible with that, and precise control over debug info is impossible. Compile to LLVM IR and/or GCC IR instead.

View on HN

A long-time disagreement between us :)

> [in C] It's very difficult to avoid undefined behavior,

True, but LLVM IR and other IRs have undefined behavior as well.

> you won't be able to modify the compiler backend (and you will want to as you start optimizing),

Not all languages need backend changes. And you can still add IR optimizations or backend changes that help your language, if you do. Yes, this might not be as easy, but then if you compile to LLVM IR, you might need IR changes for your special things anyhow.

> you can't add new language intrinsics, good GC is pretty much incompatible with that,

Good point, for most GC languages compiling to C is not a good option, which makes sense since C has no GC support.

> and precise control over debug info is impossible.

Yes, but using the C preprocessor you can get pretty far.

> Compile to LLVM IR and/or GCC IR instead.

More power that way, sure, but

1. It limits you to one compiler, while C has many.

2. LLVM IR changes over time (and recently had plenty of examples of this), so you'll need to track that. Whereas C is extremely stable, so long-term, it's much less work.

3. Emitting C is very easy (for those familiar with C), and also very easy to debug.

I think compiling to C is an excellent option. Sometimes better, sometimes worse.

  > True, but LLVM IR and other IRs have undefined behavior 
  > as well.

LLVM IR has less undefined behavior than C, and even despite the reduced surface area frontends have still historically wrestled with taming its UB (both PNaCL and Rust have documented their struggles).

  > It limits you to one compiler, while C has many.

To quote Walter Bright on this topic (which I've linked elsewhere in this thread, but here it is again: http://forum.dlang.org/post/n1vbos$11ov$1@digitalmars.com):

  > 1. You're at the mercy of bugs in the C compiler you 
  >    cannot fix.
  > 2. C leaves quite a lot as "implementation defined", 
  >    causing endless compatibility issues with various C 
  >    compilers.
  > [...]
  > 6. You'll suffer from endless bug reports caused by a 
  >    mismatch between your compiler and the user's C 
  >    compiler, whatever that might be.
  > [...]
  > 10. The order of evaluation of C code expressions is 
  >     implementation defined.
  > 11. Installation problems, again, because you don't 
  >     control the user's C compiler.

Sure, multiple implementations always brings with it those downsides you quoted. Same thing with web browsers, etc. But the benefits of multiple implementations are pretty significant as well, so it ends up worth it in some cases, and not in others.

I agree with the comparison to web browsers, but even then how much deliberately implementation-defined behavior do modern web standards contain compared to C? I can think of Javascript object property enumeration order being unspecified, but nothing else springs to mind.

There's quite a lot, I'm afraid. For example, the precision of sin/cos (this led to bugs on real websites), the precision of random numbers (this led to a bunch of recent blogposts).

And there are also non-semantic differences that end up being important, like one browser running certain things too slowly or taking too much memory.

Multiple implementations is always more complicated ;) But in many cases it's better than a monoculture, in my opinion.

Oh I'm not arguing in favor of a monoculture. But the OP's statement that "This would make it possible to leverage the C compilers that already exist for every platform out there" is naive because C's deliberate flexibility makes cross-platform and cross-compiler codegen fiendishly persnickety.

Meanwhile, the only thing that you gain from all this extra effort is the ability to target platforms that GCC and LLVM don't already support, but these platforms are all likely to be obscure resource-constrained devices, and I just can't see developers on these platforms flocking to such a thoroughly-dynamic language as the OP is envisioning.

Yes, the corner cases are quite bad. But still, C code can be remarkably portable. Back in the older days, using autoconf you could run - well written&portable - C code on a very wide variety of OSes and architectures. Since then both OSes and architectures have consolidated, so it's less noticeable I suppose.

But yes, I agree that in the context of a really dynamic language, it might not be what the author wants anyhow.

IR changes are not that significant. I followed LLVM from nearly the very beginning, and very rarely I was forced to amend something to keep up with the change. The biggest thing in the few past releases was the change in metadata (which got its own class hierarchy, separate from the values).

The very amount of tests in the LLVM source tree ensures that nobody will be motivated to do any significant change unless it is really, really needed, otherwise you'd be forced to do a lot of painful work to update all the tests.

Also, compiling to C pretty much rules out having a REPL for free and all the other fun, while with LLVM it's trivial.

Aside from metadata, some other large changes that have been going on are

* the removal of pointer types (still happening)

* the use/user flip

In my experience these have been significant in the amount of work it takes to track.

Both were not that big - at least not for the C API and text IR users. Worse for the C++ users, obviously, but that was never promised to stay stable and not covered by such a huge number of tests to deter any breaking changes.

Agreed that using the C API can be easier. But for text IR though, the changes were extensive. Scripts were provided that helped, but still, it was a bunch of work to add types/remove types due to the pointer types changes.

Related, here's Walter Bright on the difficulties of compiling to C: http://forum.dlang.org/post/n1vbos$11ov$1@digitalmars.com

Yes, he brings up some excellent points I hadn't considered. Sequence points and integral promotions are bugs waiting to happen.

Why is good GC basically incompatible with compiling to C? Because there's no portable way to scan the stack for live objects?

That, and the fact that you can't tell the compiler that it needs to be aware of pointers that can move across function calls.

In fact, there isn't any dialect of C, standard or not, that I'm aware of that allows you to do this in a fashion that works with precise, moving GC. (Mostly-copying doesn't count.) Maybe C++/CLI, but the object model you're opting into with that brings you so far from C as to barely be considered "compiling to C".

Add a hidden argument to every function marked as capable of transient reference: a pointer to a pointer to a structure (just another object) which serves as a "stack frame". In that function, if you do reference stuff, build your own "stack frame" and use that to maintain a shadow stack. If you allow threads to transiently access objects between "sync points" this won't even be all that inefficient, as you will only be using it to track sub-graph roots as you make calls to other functions... for various reasons many of the more legit mechanisms have that same limitation anyway (where threads are only stopped to be scanned at moments they mark as safe). Maybe you don't consider this to be "good gc", but if your criteria is simply "precise GC with only a minor performance penalty" I don't see any reason to doubt that C is up for the challenge. (And as you are uniquely aware, one would hope that if you were buying the static compilation argument you are also likely to not stress a garbage collector much in the first place, so I would expect the shadow stack to get very little use.) Is there something I'm missing? I really would be interested in a more expansive explanation as to why building a GC with C as a compilation target (as opposed to as a library for people you are expecting to program in C) is considered such a serious showstopping issue.

That's precise GC with a huge performance penalty, not a minor one.

The problem is not so much the spilling and reloading (though that is a large issue) as what that is going to do to the ability of the optimizer to reason about the code.

(If you're curious how I'm so sure it's a huge performance penalty, I have been spending a fair amount of time of the last month working with others to debug large performance problems caused by a variant of exactly this technique used in Servo.) :)

Do you know if you can compile to a text form of the LLVM IR? Also wondering how you'd interface with a GC if you did that.

I believe LLVM IR, even in its textual form, is not considered a stable interface.

It's not, but keeping up with upgrades generally isn't a problem. Not enough to outweigh the downsides of compiling to C.

And to be fair, it's not like the LLVM C API is going to remain the same forever, that changes too.

Last I worked on llvm-c, it was supposed to stay backwards compatible. They do add new functionality but the old API should still work until llvm 4. For rust, while we have been broken by bad code we generated and llvm bugs, I can't recall if the API ever was changed out from under us.

Yeah, you can compile to LLVM IR in assembly format and then run the result through llc. But you will pay in compilation time for this due to the serialization and deserialization steps, so I can't see a situation in which it'd be worth it to do so.

The LLVM GC interface is controlled through intrinsics, so you can access it through the human-readable IR representation just as you can with the API.

> so I can't see a situation in which it'd be worth it to do so.

The obvious one is not having a giant build time dependency that might change and be at different versions on different platforms. The text interface is far more stable.

The problem I had with doing this is how picky llvm is when it comes to ordering your temporary registers.

As far as I've seen, the text interface is radically more unstable. Like when they recently striped types from pointers, I was like "oh no that sounds like it'll be a lot of work to upgrade to", and all the backend peeps seemed to think it wasn't a big deal because LLVM's API handled it. Particularly when you factor in that any breakage in the direct LLVM API can often be resolved by looking at what Clang did when it upgraded.

That is a shame then.

In Open Dylan (http://opendylan.org/), we have a library of our own written in Dylan that lets us write out LLVM IR in binary files. We have to update it as LLVM changes, but that typically isn't all that bad.

We have some macros and a bunch of functions then that make emitting LLVM IR simpler. For example, the "ins--iterate" and "ins--if" / "ins--else" macros in this code handle phi nodes and so on:

https://github.com/dylan-lang/opendylan/blob/05271f6fec9da05...

This library is currently in the process of being updated from LLVM 3.5 to current HEAD as debug info has changed significantly upstream. After that, we will be landing some documentation for it as well.

If you're interested in learning or hearing more about this, we're typically around on #dylan on freenode IRC.

Reply on news.ycombinator.com