Bad codegen for comparison with postfix

[rikkimax]

ldc fe 2.107 as per run.dlang.org

void main()
{
    int d = 42;
    bool o = d > d++;
}

define i32 @_Dmain({ i64, ptr } %unnamed) #0 {
  %d = alloca i32, align 4                        ; [#uses = 4, size/byte = 4]
  %o = alloca i8, align 1                         ; [#uses = 1, size/byte = 1]
  store i32 42, ptr %d, align 4
  %1 = load i32, ptr %d, align 4                  ; [#uses = 2]
  %2 = add i32 %1, 1                              ; [#uses = 1]
  store i32 %2, ptr %d, align 4
  %3 = load i32, ptr %d, align 4                  ; [#uses = 1]
  %4 = icmp sgt i32 %3, %1                        ; [#uses = 1]
  %5 = zext i1 %4 to i8                           ; [#uses = 1]
  store i8 %5, ptr %o, align 1
  ret i32 0
}

Note; the icmp is after the add, which it shouldn't be.

Source: https://twitter.com/marcos_don/status/1787629240550150361

[kinke]

Thx for the report. The problem isn't the icmp after the add (that's fine), but we need to load the lhs eagerly, not using it as lvalue and loading it freshly before the icmp (so after the add + store).

[JohanEngelen]

Unclear what the exact bug is, see this post by @ibuclaw https://forum.dlang.org/post/[email protected]

Perhaps a > b is undefined/implementation-defined when evaluation of a or b changes the evaluation of the other.

[kinke]

Yeah as can be seen from the diff in #4656, this wouldn't be doable for all cases anyway, most notably if an operand is a struct or class, since that would require creating temporaries, exactly as Iain wrote in https://forum.dlang.org/post/[email protected]. So I put this on hold for now, as I wouldn't like diverging operand load orders depending on whether it's a primitive or aggregate type.

[JohanEngelen]

@rikkimax Please submit an upstream bug report, to find out what the correct solution is here (e.g. improve the spec).

[rikkimax]

Submitted https://issues.dlang.org/show_bug.cgi?id=24554