Add dexter tests using the optnone attribute in various scenarios. Our users
have found optnone useful when debugging optimised code. We have these tests
downstream (and one upstream already: D89873) and we would like to contribute
them if there is any interest.
The tests are fairly self explanatory. Testing optnone with:
* optnone-fastmath.cpp: floats and -ffast-math,
* optnone-simple-functions: simple functions and integer arithmetic,
* optnone-struct-and-methods: a struct with methods,
* optnone-vectors-and-functions: templates and integer vector arithmetic.
optnone-vectors-and-functions contains two FIXMEs. The first problem is that
lldb seems to struggle with evaluating expressions with the templates used
here (example below). Perhaps this is PR42920?
(lldb) p TypeTraits<int __attribute__((ext_vector_type(4)))>::NumElements
error: <user expression 0>:1:1: no template named 'TypeTraits'
TypeTraits<int __attribute__((ext_vector_type(4)))>::NumElements
^
The second is that while lldb cannot evaluate the following expression, gdb
can, but it reports that the variable has been optimzed away. It does this when
compiling at O0 too. llvm-dwarfdump shows that MysteryNumber does have a
location. I don't know whether the DIE is bad or if both debuggers just don't
support it.
TypeTraits<int __attribute__((ext_vector_type(4)))>::MysteryNumber
DW_TAG_variable
DW_AT_specification (0x0000006b "MysteryNumber")
DW_AT_location (DW_OP_addr 0x601028)
DW_AT_linkage_name ("_ZN10TypeTraitsIDv4_iE13MysteryNumberE")
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D97668
If the default target and host triple don't match then print the following
message when the lit test runs:
Forcing dexter tests to use host triple {HOST_TRIPLE}.
If we can't target the host arch then, when lit runs, we mark
the dexter test directories as UNSUPPORTED and print the message:
Host triple {HOST_TRIPLE} not supported. Skipping dexter tests in
the debuginfo-tests project.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D96494
Since the new pass manager has been enabled by default these tests had their
-O1 variations failing due to the tested functions being inlined. This just
adds no_inline to the respective code similar to what we did in other
tests (e.g. aa56b30014 ).
Tweak dexter-tests/memvars/inline-escaping-function.c added in D94761
(b7e516202e) by adding a 'param' use after the merge point. The test XFAILS
with and without this change, but without it the test looks very similar to
memvars/unused-merged-value.c. The test now demonstrates the problem more
clearly.
These dexter tests illustrate PR48719, the summary of which is:
Sometimes we insert dbg.values for merged values (PHIs) when promoting
variables, sometimes we don't. Sometimes there is no PHI because the merged
value is never used. It doesn't matter because LiveDebugValues understands these
merged values (implicit or otherwise) and correctly updates the debug
info. Importantly, these merged variable values (which may or may not exist as
PHIs, and may or not be represented with dbg.values) are //always// implicitly
defined by the combination of incoming edges and the incoming variable locations
along those edges by virtue of LiveDebugValues existing. Unfortunately, it is
possible to mess with the CFG and remove / move these edges before
LiveDebugValues runs. In this case our debug info model only works when the
merged value is tracked by a dbg.value. Currently, this is only done rigorously
for variables which are A) promoted in the first round of mem2reg and B) are
used after the merge point.
As an example, compile the following source with -O3 -g and step through with a
debugger. You will see parama=5 throughout the function fun which is incorrect -
we expect to see param=20 after the conditional assignment.
__attribute__((optnone))
void esc(int* p) {}
__attribute__((optnone))
void fluff() {}
__attribute__((noinline))
int fun(int parama, int paramb) {
if (parama)
parama = paramb;
fluff(); // DexLabel('s0')
esc(¶ma);
return 0;
}
int main() {
return fun(5, 20);
}
1. parama is escaped by esc(¶ma) so it is not promoted by
SROA/mem2reg (failing condition "A" above).
2. InstCombine's LowerDbgDeclare converts the dbg.declare to a set of
dbg.values (tracking the stored SSA values).
3. InstCombine replaces the two stores to parama's alloca (the initial
parameter register store in entry and the assignment in if.then) with a
PHI+store in the common sucessor.
4. SimplifyCFG folds the blocks together and converts the PHI to a
select.
The debug info is not updated to account for the merged value in the successor
prior to SimplifyCFG when it exists as a PHI, or during when it becomes a
select.
As with D89543, which added some dexter tests for escaped locals, the idea is
to build a set of source-level tests which highlights existing issues and
might be useful in evaluating a new debug info model.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D94761
both deferred_globals.cpp namespace.cpp require lldb in order to run and will
fail if it's not available.
add the required lines to the top of the tests.
deferred_globals.cpp: Verify that debug information for a local variable does
not hide a global definition that has the same name
namespace.cpp: Ensure that the debug information for a global variable
includes namespace information.
Differential Revision: https://reviews.llvm.org/D89462
Author: Nabeel Omer <nabeel.omer@sony.com>
Recently there has been renewed interest in improving debug-info for variables
that (partially or otherwise) live on the stack in optimised code.
At the moment instcombine speculates that stack slots are probably going to be
promoted to registers, and prepares the debug-info accordingly. It runs a
function called LowerDbgDeclare which converts dbg.declares to a set of
dbg.values after loads, and before stores and calls. Sometimes the stack
location remains (e.g. for escaped locals). If any dbg.values become undef
where the stack location is still valid we end up unnecessarily reducing
variable location coverage due to our inability to track multiple locations
simultaneously. There is a flag to disable this feature
(-instcombine-lower-dbg-declare=0), which prevents this conversion at the cost
of sometimes providing incorrect location info in the face of DSE, DCE, GVN,
CSE etc.
This has been discussed fairly extensively on PR34136.
The idea of these tests is to provide examples of situations that we should
consider when designing a new system, to aid discussions and eventually help
evaluate the implementation.
Dexter isn't ideal for observing specific optimisation behaviour. Writing an
exaustive test suite would be difficult, and the resultant suite would be
fragile. However, I think having some concrete executable examples is useful
at least as a reference.
Differential Revision: https://reviews.llvm.org/D89543
These tests almost certainly work on Darwin anyway, I just wanted to
keep things in a fixed, working configuration, while pushing Dexter
up.
I've left Windows unsupported as the dexter command line will need further
adjustment to run dbgeng. This can be abstracted through the %dexter
substitution, but is a task for another time.
This reverts commit cb935f3456.
Discussion in D68708 advises that green dragon is being briskly
refurbished, and it's good to have this patch up testing it.
Dexter (Debug Experience Tester) is a test-driver for our debug info
integration tests, reading a set of debug experience expectations and
comparing them with the actual behaviour of a program under a debugger.
More about Dexter can be found in the RFC:
http://lists.llvm.org/pipermail/llvm-dev/2019-October/135773.html
and the phab review in D68708. Not all the debuginfo tests have been
transformed into Dexter tests, and we look forwards to doing that
incrementally.
This commit mostly aims to flush out buildbots that are running
debuginfo-tests but don't have python 3 installed, possibly
green-dragon and some windows bots.
OCHyams