[DebugInfo@O0][Dexter] Speculated store leads to backward steps and stale values

[jmorse]

Bugzilla Link	38769
Resolution	WORKSFORME
Resolved on	Nov 01, 2018 03:13
Version	trunk
OS	Linux
Blocks	#38116
CC	@adrian-prantl,@dwblaikie,@gregbedwell,@CarlosAlbertoEnciso,@JDevlieghere,@pogo59

Extended Description

The test below, when stepped through under a debugger, mostly steps backwards through the "foo" function, and always presents the initial value of the "qux" variable, never the modified value or "optimised out".

I've used llvm/clang @ r340912 and compiled with "-O0 -g -fno-inline" for x86_64. (Inlining leads to the whole program being optimised to a return). Stepping through the "foo" function with both gdb and lldb displays, in order, the lines for:

• The if-block body
• the if-condition
• qux *= 12
• the if-condition
• return 0

Which involves two backwards steps where the original program had none. Additionally, on every instruction in "foo", "qux" has the value three (i.e. it's initial value), the multiplication by 12 never becomes visible, which is misleading. That multiply is folded into a few other operations; "qux" should probably be marked as optimised out.

This test was originally supposed to stimulate SimplifyCFGs store speculation, which merges the stores to *bar into one store.

Found using DExTer ( https://github.com/SNSystems/dexter ).

-------->8--------
int
foo(int *bar, int baz, int qux)
{
qux *= 12;
*bar = qux;
if (baz) {
*bar = baz + qux + 3;
}
return 0;
}

int
main()
{
int quux = 1;
foo(&quux, 1, 3);
return quux;
}
--------8<--------

[jmorse]

Blast, that should read "O2" there. Copy and paste fail ._.

[adrian-prantl]

Since you are filing a lot of these radars (awesome, btw!) could you please tag then in the title to differentiate bugs that reproduce at -O0 from ones that are about optimized code. It will help with prioritizing.

[jmorse]

Sure, I'll use [DebugInfo@O2] from here; for the avoidance of doubt everything I've filed so far is for -O2.

[CarlosAlbertoEnciso]

Using llvm/clang @ r345820, I am unable to reproduce the issues described in comment 0.