maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/tools/llvm-xray/X86/stack-keep-going.yaml

34 lines
1.6 KiB
YAML
Raw Normal View History

[XRay][tools] Disable windows for tests that use an unsupported shell redirect. The tests are filechecking against stderr and use some magic to make stdout go away and pipe stderr to FileCheck. This broke bots on windows. llvm-svn: 312739
2017-09-08 03:10:34 +08:00
# The redirects used in the commands to FileCheck against stderr cannot be used
# with a windows test.
#
# UNSUPPORTED: windows
[XRay][tools] Function call stack based analysis tooling for XRay traces Second try after fixing a code san problem with iterator reference types. This change introduces a subcommand to the llvm-xray tool called "stacks" which allows for analysing XRay traces provided as inputs and accounting time to stacks instead of just individual functions. This gives us a more precise view of where in a program the latency is actually attributed. The tool uses a trie data structure to keep track of the caller-callee relationships as we process the XRay traces. In particular, we keep track of the function call stack as we enter functions. While we're doing this we're adding nodes in a trie and indicating a "calls" relatinship between the caller (current top of the stack) and the callee (the new top of the stack). When we push function ids onto the stack, we keep track of the timestamp (TSC) for the enter event. When exiting functions, we are able to account the duration by getting the difference between the timestamp of the exit event and the corresponding entry event in the stack. This works even if we somehow miss the exit events for intermediary functions (i.e. if the exit event is not cleanly associated with the enter event at the top of the stack). The output of the tool currently provides just the top N leaf functions that contribute the most latency, and the top N stacks that have the most frequency. In the future we can provide more sophisticated query mechanisms and potentially an export to database feature to make offline analysis of the stack traces possible with existing tools. Differential revision: D34863 llvm-svn: 312733
2017-09-08 02:07:48 +08:00
#RUN: (llvm-xray stack %s 2>&1 1>&- || echo "Check Command Failed") | FileCheck --check-prefix HALT %s
#RUN: (llvm-xray stack -k %s 2>&1 && echo "Check Command Succeeded") | FileCheck --check-prefix KEEP-GOING-SUCCEEDS %s
#RUN: llvm-xray stack -k %s | FileCheck --check-prefix KEEP-GOING %s
---
header:
version: 1
type: 0
constant-tsc: true
nonstop-tsc: true
cycle-frequency: 2601000000
records:
- { type: 0, func-id: 1, cpu: 1, thread: 111, kind: function-enter, tsc: 10001 }
- { type: 1, func-id: 4, cpu: 1, thread: 111, kind: function-exit, tsc: 10301 }
- { type: 0, func-id: 1, cpu: 1, thread: 111, kind: function-enter, tsc: 10401 }
- { type: 0, func-id: 2, cpu: 1, thread: 111, kind: function-enter, tsc: 10501 }
- { type: 0, func-id: 3, cpu: 1, thread: 111, kind: function-enter, tsc: 10601 }
- { type: 1, func-id: 3, cpu: 1, thread: 111, kind: function-exit, tsc: 10701 }
- { type: 1, func-id: 2, cpu: 1, thread: 111, kind: function-exit, tsc: 10751 }
- { type: 1, func-id: 1, cpu: 1, thread: 111, kind: function-exit, tsc: 10775 }
...
#HALT: llvm-xray: Found record {FuncId: "#4", ThreadId: "111", RecordType: "Fn Exit"} with no matching function entry
#HALT: Check Command Failed
#KEEP-GOING-SUCCEEDS: Found record {FuncId: "#4", ThreadId: "111", RecordType: "Fn Exit"} with no matching function entry
#KEEP-GOING-SUCCEEDS: Check Command Succeeded
#KEEP-GOING: Unique Stacks: 2
# Note the interesting case here that the stack { fn-1 } is a prefix of { fn-1, fn-2, fn-3 } but they
# are still counted as unique stacks.