Hacker News Reader

Comment by nwallin | Hacker News Reader

I don't understand.

What does the "single assignment" bit get you that a compiler with an SSA pass doesn't?

Probably that the original binding of p is immutable, as it would be in a functional language: you can create a new binding, but you can't actually change the value of the existing binding.

Unless there's something I don't understand, that's what the single static assignment pass does in a compiler.

New bindings live at different addresses (if you pass a pointer to one binding, and then make a new binding with a new value, the existing pointer will point to the old value and not the new binding's value) and bindings made in a loop iteration won't live to the next iteration.

This sounds like an implementation detail. What does the language spec say about the outcome.

Different bindings are like entirely different variables that just coincidentally share the same name.

The (C) language spec says that:

  x = 5;
  int* p = &x;
  x = 6; // new binding of x
  printf("%i\n",*p);

prints "6". If new bindings lived at different addresses, it would print "5".

When the SSA pass happens in the compiler it's already too late to have guaranteed certain behaviours from the source stage...

E.g. you can turn a C program into SSA, but if you have aliasing issues, it's not gonna fix them...

An SSA pass is an implementation detail that can't change language semantics, so, as I understand, it either doesn't transform or applies only to pointers when values have externally (to the block in which they are defined) visible mutation based on the language semantics; having single assignment semantics and thereby lacking mutability is a significant property for, particularly, parallel code with shared references. If no one can mutate a reference, you don't need Rust- or Pony-like tracking of who can see or mutate it, it's safe for everyone to see it.

I assume the removal of pointer aliasing?

Reply on news.ycombinator.com