All of lore.kernel.org
 help / color / mirror / Atom feed
From: Evgeny Roubinchtein <zhenya1007@gmail.com>
To: lttng-dev@lists.lttng.org
Subject: How do tracepoint macros interact with the optimizer?
Date: Thu, 17 Nov 2016 10:34:59 -0500	[thread overview]
Message-ID: <CAGYXaSbnjG1Sh8bx5B2vcsAsfaOKo66yr6-Lt+saZPuuyAJDpg__4788.2690596909$1479397235$gmane$org@mail.gmail.com> (raw)


[-- 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

             reply	other threads:[~2016-11-17 15:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-17 15:34 Evgeny Roubinchtein [this message]
     [not found] <CAGYXaSbnjG1Sh8bx5B2vcsAsfaOKo66yr6-Lt+saZPuuyAJDpg@mail.gmail.com>
2016-11-17 16:50 ` How do tracepoint macros interact with the optimizer? Mathieu Desnoyers
     [not found] ` <32594678.5908.1479401406952.JavaMail.zimbra@efficios.com>
2016-11-17 17:18   ` Evgeny Roubinchtein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGYXaSbnjG1Sh8bx5B2vcsAsfaOKo66yr6-Lt+saZPuuyAJDpg__4788.2690596909$1479397235$gmane$org@mail.gmail.com' \
    --to=zhenya1007@gmail.com \
    --cc=lttng-dev@lists.lttng.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.