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

27 lines
1.4 KiB
YAML
Raw Normal View History

Fix llvm-xray tests to avoid subshells We already uses pipefail to detect failure of a redirected command, so the "|| echo failure" construct was unnecessary. These tests run and pass on Windows now. llvm-svn: 312747
2017-09-08 05:28:09 +08:00
# RUN: not llvm-xray stack %s 2>&1 | FileCheck --check-prefix HALT %s
# RUN: llvm-xray stack -k %s 2>&1 | FileCheck --check-prefix KEEP-GOING-SUCCEEDS %s
# RUN: llvm-xray stack -k %s | FileCheck --check-prefix KEEP-GOING %s
[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
---
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 }
...
Fix llvm-xray tests to avoid subshells We already uses pipefail to detect failure of a redirected command, so the "|| echo failure" construct was unnecessary. These tests run and pass on Windows now. llvm-svn: 312747
2017-09-08 05:28:09 +08:00
# HALT: llvm-xray: Found record {FuncId: "#4", ThreadId: "111", RecordType: "Fn Exit"} with no matching function entry
[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
#KEEP-GOING-SUCCEEDS: Found record {FuncId: "#4", ThreadId: "111", RecordType: "Fn Exit"} with no matching function entry
#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.