* How do tracepoint macros interact with the optimizer?
@ 2016-11-17 15:34 Evgeny Roubinchtein
0 siblings, 0 replies; 3+ messages in thread
From: Evgeny Roubinchtein @ 2016-11-17 15:34 UTC (permalink / raw)
To: lttng-dev
[-- Attachment #1.1: Type: text/plain, Size: 1492 bytes --]
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).
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").
Please Cc me on replies as I am not subscribed to the list.
Thank you in advance!
--
Best,
Zhenya
[-- Attachment #1.2: Type: text/html, Size: 1810 bytes --]
[-- Attachment #2: Type: text/plain, Size: 156 bytes --]
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
^ permalink raw reply [flat|nested] 3+ messages in thread[parent not found: <CAGYXaSbnjG1Sh8bx5B2vcsAsfaOKo66yr6-Lt+saZPuuyAJDpg@mail.gmail.com>]
* Re: How do tracepoint macros interact with the optimizer? [not found] <CAGYXaSbnjG1Sh8bx5B2vcsAsfaOKo66yr6-Lt+saZPuuyAJDpg@mail.gmail.com> @ 2016-11-17 16:50 ` Mathieu Desnoyers [not found] ` <32594678.5908.1479401406952.JavaMail.zimbra@efficios.com> 1 sibling, 0 replies; 3+ messages in thread From: Mathieu Desnoyers @ 2016-11-17 16:50 UTC (permalink / raw) To: Evgeny Roubinchtein; +Cc: lttng-dev [-- Attachment #1.1: Type: text/plain, Size: 2925 bytes --] ---- On Nov 17, 2016, at 10:34 AM, Evgeny Roubinchtein <zhenya1007@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@lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com [-- Attachment #1.2: Type: text/html, Size: 4777 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <32594678.5908.1479401406952.JavaMail.zimbra@efficios.com>]
* Re: How do tracepoint macros interact with the optimizer? [not found] ` <32594678.5908.1479401406952.JavaMail.zimbra@efficios.com> @ 2016-11-17 17:18 ` Evgeny Roubinchtein 0 siblings, 0 replies; 3+ messages in thread From: Evgeny Roubinchtein @ 2016-11-17 17:18 UTC (permalink / raw) To: Mathieu Desnoyers; +Cc: lttng-dev [-- Attachment #1.1: Type: text/plain, Size: 3289 bytes --] 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@efficios.com> wrote: > ---- On Nov 17, 2016, at 10:34 AM, Evgeny Roubinchtein < > zhenya1007@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@lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > > -- > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com > [-- Attachment #1.2: Type: text/html, Size: 5568 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-11-17 17:19 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-17 15:34 How do tracepoint macros interact with the optimizer? Evgeny Roubinchtein
[not found] <CAGYXaSbnjG1Sh8bx5B2vcsAsfaOKo66yr6-Lt+saZPuuyAJDpg@mail.gmail.com>
2016-11-17 16:50 ` Mathieu Desnoyers
[not found] ` <32594678.5908.1479401406952.JavaMail.zimbra@efficios.com>
2016-11-17 17:18 ` Evgeny Roubinchtein
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.