How does Rebindable suppress the compiler's optimizations for immutable?

[H. S. Teoh]

On Fri, Feb 15, 2019 at 03:50:33AM -0700, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Friday, February 15, 2019 3:06:34 AM MST Kagamin via Digitalmars-d-learn 
> wrote:
> > Union is just a pretty cast, type system guarantees don't hold for
> > it.
> 
> Well, technically, what's supposed to be the case is that when you
> cast, the type system guarantees still hold but it's up to the
> programmer to make sure that they do - just like how it's up to the
> programmer to ensure that @trusted code is really @safe.

Currently the compiler will automatically mark any code as @system that
tries to access a union field that involves a pointer overlapping with a
non-pointer.  So you cannot just get away from @safe just by using a
union.

In the same vein, I think any attempt to access a union that contains
overlapping immutable / non-immutable fields should automatically taint
the immutable value somehow so that no unsafe optimizations happen based
on immutability.  But that gets into the tricky territory of what
happens if you assign an overlapping immutable field to an immutable
local variable, and then access the local variable -- will the compiler
optimize based on immutable, which may be invalid because of the union?

I'm tempted to say that a union that mixes immutable / mutable ought to
be illegal.  How can you possibly guarantee anything about immutability
if it overlaps with mutable fields??  It makes no sense.  At the very
least, such code should be automatically @system.  At the @system level
sometimes you have to do exactly this -- e.g., the GC may allocate a
segment of memory for an immutable variable, but during the pointer scan
the GC has a mutable reference to the immutable memory (it has to, since
at some point when the memory is collected the GC has to be able to
reassign it to mutable data again), and it's basically a matter of trust
that that GC doesn't go about modifying immutable data.  (Which brings
up interesting questions about how immutability might interact with a
moving / compacting GC that may need to rewrite potentially immutable
pointers. But that's tangential to this discussion.)

So anyway, all of this seems to suggest that optimizations based on
immutable really only can take place meaningfully within @safe code,
provided we make accessing immutables in union with mutables a @system
operation.  All interactions between immutable-optimized @safe code and
potentially immutable-breaking @system code would then be forced to take
place through @trusted APIs, which would seem to be the correct design.


> Rebindable is a pretty weird case with what it's doing, but I'm pretty
> sure that it's actually violating the type system with what it does in
> that you can't rely on the value of the immutable reference itself not
> being mutated even though it's immutable. The type system guarantees
> for what the reference refers to are maintained but not the guarantees
> for the actual reference. In practice, I don't think that it's
> actually a problem, but in principle, it's violating the type system,
> and a particularly aggressive optimizer could make a bad assumption.
> However, given that a union is involved, and as such the "cast" is
> built into the type, I question that any optimizer would ever make the
> wrong assumption about Rebindable.
[...]

It probably only means that current D compilers aren't optimizing based
on immutable like they're supposedly able to.  If/when optimizers start
taking advantage of this, we're going to see UB in many more places than
we may realize currently.

I think the correct approach is to restrict immutable optimizations to
only @safe code, and force all immutable casts, including accessing
immutables in unions where they might overlap with mutables, a @system
operation, thus mandating any interaction with immutable optimizations
via @trusted interfaces.


T

-- 
In order to understand recursion you must first understand recursion.