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

[Evgeny Roubinchtein]

Hi, Mathieu,

Thank you for a quick and informative reply.  I really appreciate it.

Should I have more questions, I'll ask, but, for now, I think I am in good
shape. :-)

-- 
Best,
Zhenya

On Thu, Nov 17, 2016 at 11:50 AM, Mathieu Desnoyers <
mathieu.desnoyers at efficios.com> wrote:

> ---- 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/f23b3a84/attachment.html>