thr3ads.net - llvm dev - [llvm-dev] Conditional jump or move depends on uninitialised value(s) [Nov 2016]

If this information is useful, please help other people find it:
Share via:

regehr via llvm-dev

2016-Nov-21 23:38 UTC

[llvm-dev] Conditional jump or move depends on uninitialised value(s)

I spent some time digging into a Valgrind report of uninitialized values 
in LLVM r287520 built using itself.  (One of quite a few such reports 
that comes up during a "make check".)

I could use another set of eyes on the issue if someone has time.

This command gives me an error:

valgrind -q ./bin/llc < 
/home/regehr/llvm/test/CodeGen/Hexagon/hwloop-dbg.ll -march=hexagon 
-mcpu=hexagonv4

The error is at this line:

https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/DeadMachineInstructionElim.cpp#L142

Here I've refactored the code into a minimal (noinline) function that 
still triggers the problem.  xfunc2() and xfunc3() are also noinline. 
The problem goes away if either isReg() or isDef() is marked noinline.

void xfuncx(const MachineOperand &MO,
	    const TargetRegisterInfo *TRI,
	   BitVector &LivePhysRegs)  {
   if (MO.isReg() &&  // <<<<------ problem reported here
       MO.isDef()) {
     xfunc2(MO, TRI, LivePhysRegs);
   } else {
     xfunc3(MO, LivePhysRegs);
   }
}

The asm is below.  Maybe I've been staring too long but I don't see the 
problem Valgrind is talking about.

John


	.section 
.text._Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE,"ax",
at progbits
	.globl 
_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE
	.p2align	4, 0x90
	.type 
_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE, at
function
_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE: 
# 
@_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE
.Lfunc_begin4:
	.loc	2 126 0                 # 
../lib/CodeGen/DeadMachineInstructionElim.cpp:126:0
	.cfi_startproc
# BB#0:                                 # %entry
	#DEBUG_VALUE: xfuncx:MO <- %RDI
	#DEBUG_VALUE: xfuncx:TRI <- %RSI
	#DEBUG_VALUE: xfuncx:LivePhysRegs <- %RDX
	#DEBUG_VALUE: isReg:this <- %RDI
	.loc	2 127 18 prologue_end   # 
../lib/CodeGen/DeadMachineInstructionElim.cpp:127:18
	movl	$16777471, %eax         # imm = 0x10000FF
	andl	(%rdi), %eax
.Ltmp128:
	#DEBUG_VALUE: isReg:this <- %RDI
	cmpl	$16777216, %eax         # imm = 0x1000000
	jne	.LBB4_2
# BB#1:                                 # %if.then
	#DEBUG_VALUE: xfuncx:LivePhysRegs <- %RDX
	#DEBUG_VALUE: xfuncx:TRI <- %RSI
	#DEBUG_VALUE: xfuncx:MO <- %RDI
.Ltmp129:
	.loc	2 129 5                 # 
../lib/CodeGen/DeadMachineInstructionElim.cpp:129:5
	jmp 
_Z6xfunc2RKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE at
PLT
# TAILCALL
.Ltmp130:
.LBB4_2:                                # %if.else
	#DEBUG_VALUE: xfuncx:LivePhysRegs <- %RDX
	#DEBUG_VALUE: xfuncx:TRI <- %RSI
	#DEBUG_VALUE: xfuncx:MO <- %RDI
	.loc	2 131 5                 # 
../lib/CodeGen/DeadMachineInstructionElim.cpp:131:5
	movq	%rdx, %rsi
	jmp	_Z6xfunc3RKN4llvm14MachineOperandERNS_9BitVectorE at PLT # TAILCALL
.Ltmp131:
.Lfunc_end4:
	.size 
_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE, 
.Lfunc_end4-_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE
	.cfi_endproc

regehr via llvm-dev

2016-Nov-22 05:48 UTC

head link

[llvm-dev] Conditional jump or move depends on uninitialised value(s)

Alright, here's what seems to be happening...

The testcase mentioned below builds a MachineOperand that prints like this:

<BB#2>

The bottom word of this MachineOperand now looks like this, with 
(according to Valgrind) the x's corresponding to uninitialized bits:

xxxx xxxx xxxx 0000 0000 0000 0000 0100

At this point isReg() can be called safely since it looks only at the 
lower bits.  isDef() cannot be called safely because it looks at bit 25. 
  However it is clear that the C++ code (below) never calls isDef() when 
isReg() returns false, as it does here.

So now back to the asm:

0000000000000000 
<_Z6xfuncxPKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoEPNS_9BitVectorE>:
    0:	b8 ff 00 00 01       	mov    $0x10000ff,%eax
    5:	23 07                	and    (%rdi),%eax
    7:	3d 00 00 00 01       	cmp    $0x1000000,%eax
    c:	75 05                	jne    13 
<_Z6xfuncxPKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoEPNS_9BitVectorE+0x13>
    e:	e9 00 00 00 00       	jmpq   13 
<_Z6xfuncxPKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoEPNS_9BitVectorE+0x13>
   13:	48 89 d6             	mov    %rdx,%rsi
   16:	e9 00 00 00 00       	jmpq   1b <.LCPI5_1+0xb>

It grabs the low word of the MO and uses a mask to grab bit 25 and also 
the low 8 bits.  Next, it branches on bit 25, which isn't initialized. 
The code is clever but -- I think -- wrong.

GCC does the right thing here, first branching on the low bits and only 
then looking at bit 25.

Sorry if I got anything wrong here!

John



On 11/21/2016 04:38 PM, regehr via llvm-dev wrote:> I spent some time digging into a Valgrind report of uninitialized values
> in LLVM r287520 built using itself.  (One of quite a few such reports
> that comes up during a "make check".)
>
> I could use another set of eyes on the issue if someone has time.
>
> This command gives me an error:
>
> valgrind -q ./bin/llc <
> /home/regehr/llvm/test/CodeGen/Hexagon/hwloop-dbg.ll -march=hexagon
> -mcpu=hexagonv4
>
> The error is at this line:
>
>
https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/DeadMachineInstructionElim.cpp#L142
>
>
> Here I've refactored the code into a minimal (noinline) function that
> still triggers the problem.  xfunc2() and xfunc3() are also noinline.
> The problem goes away if either isReg() or isDef() is marked noinline.
>
> void xfuncx(const MachineOperand &MO,
>         const TargetRegisterInfo *TRI,
>        BitVector &LivePhysRegs)  {
>   if (MO.isReg() &&  // <<<<------ problem reported
here
>       MO.isDef()) {
>     xfunc2(MO, TRI, LivePhysRegs);
>   } else {
>     xfunc3(MO, LivePhysRegs);
>   }
> }
>
> The asm is below.  Maybe I've been staring too long but I don't see
the
> problem Valgrind is talking about.
>
> John
>
>
>     .section
>
.text._Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE,"ax",
at progbits
>
>     .globl
> _Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE
>     .p2align    4, 0x90
>     .type
>
_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE, at
function
>
>
_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE:
> #
>
@_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE
>
> .Lfunc_begin4:
>     .loc    2 126 0                 #
> ../lib/CodeGen/DeadMachineInstructionElim.cpp:126:0
>     .cfi_startproc
> # BB#0:                                 # %entry
>     #DEBUG_VALUE: xfuncx:MO <- %RDI
>     #DEBUG_VALUE: xfuncx:TRI <- %RSI
>     #DEBUG_VALUE: xfuncx:LivePhysRegs <- %RDX
>     #DEBUG_VALUE: isReg:this <- %RDI
>     .loc    2 127 18 prologue_end   #
> ../lib/CodeGen/DeadMachineInstructionElim.cpp:127:18
>     movl    $16777471, %eax         # imm = 0x10000FF
>     andl    (%rdi), %eax
> .Ltmp128:
>     #DEBUG_VALUE: isReg:this <- %RDI
>     cmpl    $16777216, %eax         # imm = 0x1000000
>     jne    .LBB4_2
> # BB#1:                                 # %if.then
>     #DEBUG_VALUE: xfuncx:LivePhysRegs <- %RDX
>     #DEBUG_VALUE: xfuncx:TRI <- %RSI
>     #DEBUG_VALUE: xfuncx:MO <- %RDI
> .Ltmp129:
>     .loc    2 129 5                 #
> ../lib/CodeGen/DeadMachineInstructionElim.cpp:129:5
>     jmp
> _Z6xfunc2RKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE
at PLT
> # TAILCALL
> .Ltmp130:
> .LBB4_2:                                # %if.else
>     #DEBUG_VALUE: xfuncx:LivePhysRegs <- %RDX
>     #DEBUG_VALUE: xfuncx:TRI <- %RSI
>     #DEBUG_VALUE: xfuncx:MO <- %RDI
>     .loc    2 131 5                 #
> ../lib/CodeGen/DeadMachineInstructionElim.cpp:131:5
>     movq    %rdx, %rsi
>     jmp    _Z6xfunc3RKN4llvm14MachineOperandERNS_9BitVectorE at PLT #
TAILCALL
> .Ltmp131:
> .Lfunc_end4:
>     .size
>
_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE,
>
.Lfunc_end4-_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE
>
>     .cfi_endproc
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

regehr via llvm-dev

2016-Nov-22 06:06 UTC

head link

[llvm-dev] Conditional jump or move depends on uninitialised value(s)

Just want to emphasize that on x86-64 and using Valgrind:

LLVM compiled with LLVM gets 360 unexpected test fails

LLVM compiled with GCC gets 22 unexpected test fails

Of course I don't know how many of these are caused by this bitfield 
speculation issue.

John


On 11/21/2016 10:48 PM, regehr via llvm-dev wrote:> Alright, here's what seems to be happening...
>
> The testcase mentioned below builds a MachineOperand that prints like this:
>
> <BB#2>
>
> The bottom word of this MachineOperand now looks like this, with
> (according to Valgrind) the x's corresponding to uninitialized bits:
>
> xxxx xxxx xxxx 0000 0000 0000 0000 0100
>
> At this point isReg() can be called safely since it looks only at the
> lower bits.  isDef() cannot be called safely because it looks at bit 25.
>  However it is clear that the C++ code (below) never calls isDef() when
> isReg() returns false, as it does here.
>
> So now back to the asm:
>
> 0000000000000000
>
<_Z6xfuncxPKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoEPNS_9BitVectorE>:
>
>    0:    b8 ff 00 00 01           mov    $0x10000ff,%eax
>    5:    23 07                    and    (%rdi),%eax
>    7:    3d 00 00 00 01           cmp    $0x1000000,%eax
>    c:    75 05                    jne    13
>
<_Z6xfuncxPKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoEPNS_9BitVectorE+0x13>
>
>    e:    e9 00 00 00 00           jmpq   13
>
<_Z6xfuncxPKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoEPNS_9BitVectorE+0x13>
>
>   13:    48 89 d6                 mov    %rdx,%rsi
>   16:    e9 00 00 00 00           jmpq   1b <.LCPI5_1+0xb>
>
> It grabs the low word of the MO and uses a mask to grab bit 25 and also
> the low 8 bits.  Next, it branches on bit 25, which isn't initialized.
> The code is clever but -- I think -- wrong.
>
> GCC does the right thing here, first branching on the low bits and only
> then looking at bit 25.
>
> Sorry if I got anything wrong here!
>
> John
>
>
>
> On 11/21/2016 04:38 PM, regehr via llvm-dev wrote:
>> I spent some time digging into a Valgrind report of uninitialized
values
>> in LLVM r287520 built using itself.  (One of quite a few such reports
>> that comes up during a "make check".)
>>
>> I could use another set of eyes on the issue if someone has time.
>>
>> This command gives me an error:
>>
>> valgrind -q ./bin/llc <
>> /home/regehr/llvm/test/CodeGen/Hexagon/hwloop-dbg.ll -march=hexagon
>> -mcpu=hexagonv4
>>
>> The error is at this line:
>>
>>
https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/DeadMachineInstructionElim.cpp#L142
>>
>>
>>
>> Here I've refactored the code into a minimal (noinline) function
that
>> still triggers the problem.  xfunc2() and xfunc3() are also noinline.
>> The problem goes away if either isReg() or isDef() is marked noinline.
>>
>> void xfuncx(const MachineOperand &MO,
>>         const TargetRegisterInfo *TRI,
>>        BitVector &LivePhysRegs)  {
>>   if (MO.isReg() &&  // <<<<------ problem reported
here
>>       MO.isDef()) {
>>     xfunc2(MO, TRI, LivePhysRegs);
>>   } else {
>>     xfunc3(MO, LivePhysRegs);
>>   }
>> }
>>
>> The asm is below.  Maybe I've been staring too long but I don't
see the
>> problem Valgrind is talking about.
>>
>> John
>>
>>
>>     .section
>>
.text._Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE,"ax",
at progbits
>>
>>
>>     .globl
>>
_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE
>>
>>     .p2align    4, 0x90
>>     .type
>>
_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE, at
function
>>
>>
>>
_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE:
>>
>> #
>>
@_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE
>>
>>
>> .Lfunc_begin4:
>>     .loc    2 126 0                 #
>> ../lib/CodeGen/DeadMachineInstructionElim.cpp:126:0
>>     .cfi_startproc
>> # BB#0:                                 # %entry
>>     #DEBUG_VALUE: xfuncx:MO <- %RDI
>>     #DEBUG_VALUE: xfuncx:TRI <- %RSI
>>     #DEBUG_VALUE: xfuncx:LivePhysRegs <- %RDX
>>     #DEBUG_VALUE: isReg:this <- %RDI
>>     .loc    2 127 18 prologue_end   #
>> ../lib/CodeGen/DeadMachineInstructionElim.cpp:127:18
>>     movl    $16777471, %eax         # imm = 0x10000FF
>>     andl    (%rdi), %eax
>> .Ltmp128:
>>     #DEBUG_VALUE: isReg:this <- %RDI
>>     cmpl    $16777216, %eax         # imm = 0x1000000
>>     jne    .LBB4_2
>> # BB#1:                                 # %if.then
>>     #DEBUG_VALUE: xfuncx:LivePhysRegs <- %RDX
>>     #DEBUG_VALUE: xfuncx:TRI <- %RSI
>>     #DEBUG_VALUE: xfuncx:MO <- %RDI
>> .Ltmp129:
>>     .loc    2 129 5                 #
>> ../lib/CodeGen/DeadMachineInstructionElim.cpp:129:5
>>     jmp
>>
_Z6xfunc2RKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE at
PLT
>>
>> # TAILCALL
>> .Ltmp130:
>> .LBB4_2:                                # %if.else
>>     #DEBUG_VALUE: xfuncx:LivePhysRegs <- %RDX
>>     #DEBUG_VALUE: xfuncx:TRI <- %RSI
>>     #DEBUG_VALUE: xfuncx:MO <- %RDI
>>     .loc    2 131 5                 #
>> ../lib/CodeGen/DeadMachineInstructionElim.cpp:131:5
>>     movq    %rdx, %rsi
>>     jmp    _Z6xfunc3RKN4llvm14MachineOperandERNS_9BitVectorE at PLT #
>> TAILCALL
>> .Ltmp131:
>> .Lfunc_end4:
>>     .size
>>
_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE,
>>
>>
.Lfunc_end4-_Z6xfuncxRKN4llvm14MachineOperandEPKNS_18TargetRegisterInfoERNS_9BitVectorE
>>
>>
>>     .cfi_endproc
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Possibly Parallel Threads

Search for more maybe matching threads

llvm dev - Nov 2016 - Conditional jump or move depends on uninitialised value(s)

[llvm-dev] Conditional jump or move depends on uninitialised value(s)

[llvm-dev] Conditional jump or move depends on uninitialised value(s)

[llvm-dev] Conditional jump or move depends on uninitialised value(s)

Possibly Parallel Threads