[GDC] Evaluation order: Please update the dmd backend

[Sarath Kodali]

On Tuesday, 1 April 2014 at 11:50:51 UTC, Johannes Pfau wrote:
> I started fixing GDC bug #8 (*) which is basically that array op
> evaluation order currently depends on the target architecture. 
> Consider
> this example:
> a()[] = b()[] + c()[];
> The order in which c,a,b are called is currently architecture 
> specific.
> As stated in that bug report by Andrei we want this to evaluate 
> LTR, so
> a() first, then b(), then c().
>
> These operations are actually rewritten to calls to extern(C)
> functions. Arguments to C function should be evaluated LTR as 
> well, but
> dmd currently evaluates them RTL (GDC: architecture dependent). 
> In order
> to fix the array op bug in gdc we have to define the evaluation 
> order
> for extern(C) function parameters.
>
> So I've changed extern(C) functions to evaluate LTR in GDC and 
> then had
> to change the array op code, cause that assumed extern(C) 
> function
> evaluate RTL. Now I'd like to push these array op changes into 
> dmd as we
> want to keep as few gdc specific changes as possible and dmd 
> (and ldc)
> will need these changes anyway as soon as they implement 
> extern(C)
> functions as LTR. This is required by dmd issue #6620 (**) and 
> the
> language spec (***).
>
> However, if we apply only these changes the array op order 
> reverses for
> DMD as it evaluates extern(C) function arguments RTL.
>
> So I need someone with dmd backend knowledge to fix the 
> evaluation
> order of extern(C) function parameters to be LTR.
> Evaluation order of assignments should also be fixed to be LTR 
> in the
> dmd backend. Although not strictly required for the array op 
> changes
> it'd be inconsistent to have array op assignments execute LTR 
> but
> normal assignments RTL:
> a()[] = b()[] + c()[]; //Array op assignment
> a() = b() + c();       //Normal assignment
>  |      |    |
>  1      2    3
>
> The frontend changes for dmd are here:
> https://github.com/jpf91/dmd/tree/fixOrder
> Frontend:
> https://github.com/jpf91/dmd/commit/5d61b812977dbdc1f99100e2fbaf1f45e9d25b03
> Test cases:
> https://github.com/jpf91/dmd/commit/82bffe0862b272f02c27cc428b22a7dd113b4a07
>
> Druntime changes (need to be applied at the same time as dmd 
> changes)
> https://github.com/jpf91/druntime/tree/fixOrder
> https://github.com/jpf91/druntime/commit/f3f6f49c595d4fb25fb298e435ad1874abac516d
>
>
> (*)   http://bugzilla.gdcproject.org/show_bug.cgi?id=8
> (**)  https://d.puremagic.com/issues/show_bug.cgi?id=6620
> (***) https://github.com/D-Programming-Language/dlang.org/pull/6

The evaluation order of assign operators should not be LTR as 
they have right associativity. In "a = b = c", c has to be 
evaluated first, then b and then a. Similarly, in "a = b + c", 
"b+c" has to be evaluated first before a is evaluated. Otherwise 
it will be very confusing, that in some cases it is LTR and in 
some it is RTL.
Other binary operators like "+" have left associativity, and 
hence evaluation for these should be LTR as mentioned in D spec.

The C spec requires that the function arguments are to be pushed 
in RTL order.
The DMD codegen uses pushl x86 instructions for pushing args. If 
the frontend changes the func args evaluation order to LTR, then 
the backend has to be modified to use mov x86 instructions as is 
done by gcc codegen.

- Sarath