[PATCH] D31345: [XRay] [compiler-rt] Unwriting FDR mode buffers when functions are short.

[Keith via Phabricator via llvm-commits]

kpw created this revision.

Here short is just hard coded, but buffer rewinding happens for both exits and
tail exits.

With this approach, we'll handle certain cases well, but I'm wondering whether
we should adopt more elaborate strategies for:

1. Recursive TCO. E.g. For a factorial function called like fact(3, 1), -opt

might create a call sequence like:
main   <-------
CALL fact;    |
CALL fact;    | return
CALL fact;    |
TAIL_EXIT fact;

We would only end up rewinding the log until the first match and would be left
with two records of junk that will never have any corresponding EXIT records.

Example corresponding source:

int fact(int a, int b) { if (a == 1) return b; return fact(a - 1, b * a); }

2. Tail calls that are invoked from non-instrumented functions. Do we have any

guards in the compile stage to prevent tail call invocation of an instrumented
function by a non-instrumented one?

For instance:
main
Call Instrumented1
Call NotInstrumented;<----
Call Instrumented2;      |
TAIL_EXIT NotInstrumented;

The problem with this example is that we won't ever have matching FunctionEntry
record for NotInstrumented, so the linear search might go too far up the call
stack and wipe out the FunctionEntry record for Instrumented1.

A way we could possibly handle this case is if the sleds encode the function id
for the *instrumented* function id that is highest on the call stack. That way
the TAIL exit record logged would match to the Instrumented2 entry in this
example.


https://reviews.llvm.org/D31345

Files:
  lib/xray/xray_fdr_logging_impl.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D31345.92984.patch
Type: text/x-patch
Size: 6920 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170324/7068be30/attachment.bin>