[Issue 14952] New: Redundant REX.W before FSTP confuses Valgrind

[via Digitalmars-d-bugs]

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

          Issue ID: 14952
           Summary: Redundant REX.W before FSTP confuses Valgrind
           Product: D
           Version: D2
          Hardware: x86_64
                OS: All
            Status: NEW
          Keywords: wrong-code
          Severity: regression
          Priority: P1
         Component: dmd
          Assignee: nobody at puremagic.com
          Reporter: thecybershadow at gmail.com

For this code:

//////// test.d ////////
real f() { return 123; }

void main()
{
    auto x = f() / f();
}
////////////////////////

DMD outputs the following x86_64 opcodes:

55                                   push    rbp
48 8B EC                             mov     rbp, rsp
48 83 EC 20                          sub     rsp, 20h
48 83 EC 20                          sub     rsp, 20h
E8 87 FF FF FF                       call    _D4test1fFZe
48 83 C4 20                          add     rsp, 20h
48 83 EC 20                          sub     rsp, 20h
48 DB BD E0 FF FF FF                 fstp    [rbp+var_20]
E8 73 FF FF FF                       call    _D4test1fFZe
48 83 C4 20                          add     rsp, 20h
48 DB AD E0 FF FF FF                 fld     [rbp+var_20]
DE F1                                fdivrp  st(1), st
DB 7D F0                             fstp    [rbp+var_10]
31 C0                                xor     eax, eax
48 8D 65 00                          lea     rsp, [rbp+0]
5D                                   pop     rbp
C3                                   retn

Note the "48 DB BD" sequence. As I understand, the 48 prefix (REX.W) is
redundant in that situation, and it also confuses Valgrind:

vex amd64->IR: unhandled instruction bytes: 0x48 0xDB 0xBD 0x10 0xFE 0xFF 0xFF
0x48
vex amd64->IR:   REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==20966== valgrind: Unrecognised instruction at address 0x4de3c7.
==20966==    at 0x4DE3C7: Div(Type*, Expression*, Expression*) (in
/home/digger/2/work/build/bin/dmd)
==20966==    by 0x5BA95A: Expression_optimize::OptimizeVisitor::visit(DivExp*)
(in /home/digger/2/work/build/bin/dmd)
==20966==    by 0x566C64: DivExp::accept(Visitor*) (in
/home/digger/2/work/build/bin/dmd)
==20966==    by 0x5B9223: Expression_optimize(Expression*, int, bool) (in
/home/digger/2/work/build/bin/dmd)
==20966==    by 0x54748C: Expression::optimize(int, bool) (in
/home/digger/2/work/build/bin/dmd)
==20966==    by 0x4EC7E1: implicitConvTo::ImplicitConvTo::visit(Expression*)
(in /home/digger/2/work/build/bin/dmd)
==20966==    by 0x5EA489: Visitor::visit(BinExp*) (in
/home/digger/2/work/build/bin/dmd)
==20966==    by 0x5EA981: Visitor::visit(DivExp*) (in
/home/digger/2/work/build/bin/dmd)
==20966==    by 0x566C64: DivExp::accept(Visitor*) (in
/home/digger/2/work/build/bin/dmd)
==20966==    by 0x4EC747: implicitConvTo(Expression*, Type*) (in
/home/digger/2/work/build/bin/dmd)
==20966==    by 0x546414: Expression::implicitConvTo(Type*) (in
/home/digger/2/work/build/bin/dmd)
==20966==    by 0x58A972: ExpInitializer::semantic(Scope*, Type*,
NeedInterpret) (in /home/digger/2/work/build/bin/dmd)

Because DMD is now used to build DMD, this manifests as a regression, and
interferes with services such as http://digger.k3.1azy.net/trend/ which rely on
the ability of running DMD under Valgrind to gather statistical information.

--