[lttng-dev] How do tracepoint macros interact with the optimizer?

[Mathieu Desnoyers]

---- On Nov 17, 2016, at 10:34 AM, Evgeny Roubinchtein <zhenya1007 at gmail.com> wrote: 

> Dear LTTNG users and developers,
> I would like to know how the tracepoint macro interacts with the compiler's code
> optimizer (I am specifically interested in GCC 4.9 if that makes a difference).

> Suppose I add a tracepoint to the section of code that the optimizer would have
> eliminated, and then compile with optimization. What happens? Does the
> optimizer eliminate the statement(s) that the tracepoint macro expands to? Or
> does the tracepoint macro do something to force the optimizer to keep the
> statement(s) in? (e.g., declare some variable volatile, or some moral
> equivalent).

If you put a tracepoint in dead code, it will prevent dead code elimination, because 
the code is not dead anymore: it now has a side-effect, which is to call the tracepoint 
callbacks if there are any ever connected. Also, reading the "state" variable is done 
with a volatile load, which is considered as another side-effect. 

> Now essentially the same question about local variables. To make things simple,
> let's imagine that my tracepoint definition has a single variable declared
> inside TP_ARGS, i.e., something like:
> TRACEPOINT_EVENT (
> my_provider, my_trace_point
> TP_ARGS (int, foo_arg),
> TP_FIELDS( ctf_integer(int, foo, foo_arg)))
> Let's also imagine that, in my code, I have an automatic local variable, (let's
> call it `bar`) that would normally be "optimized out", and I add a tracepoint
> statement that references "bar", and compile with optimization. What happens?
> Specifically, can it happen that the optimizer is now prevented from
> "optimizing out" `bar`, and is, e.g., forced to stack-allocated it (rather than
> keeping it in a register, or whatever other techniques it employs to "optimize
> it out").

Adding a tracepoint adds liveness contraints (this is on purpose). 
So it may increase register pressure, or in some situations require 
to save/reload the variable from the stack, but note that such reload 
would be done within the "unlikely" if() branch, so loading such variable 
from the stack would only affect "tracing active" case. 

As a rule of thumb, you may want to keep your static tracepoints 
close to where variables are actually used by the application. 

Another aspect to consider with respect to optimisations: if you 
put a tracepoint in a "leaf" function, the function call of the tracepoint 
turns it into a non-leaf function. 

Those are very relevant questions :) Let me know if you need 
further clarification. 

Thanks, 

Mathieu 

> Please Cc me on replies as I am not subscribed to the list.

> Thank you in advance!

> --
> Best,
> Zhenya

> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20161117/6175e5cc/attachment.html>