public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Malcolm <dmalcolm@redhat.com>
To: Dibyendu Majumdar <mobile@majumdar.org.uk>
Cc: jit@gcc.gnu.org
Subject: Re: lvalues and rvalues
Date: Thu, 01 Jan 2015 00:00:00 -0000	[thread overview]
Message-ID: <1434328706.3192.17.camel@surprise> (raw)
In-Reply-To: <CACXZuxemh6PZS1deAj39FmGRsjkTYrLtDRJqDZnvBK2REo-gZA@mail.gmail.com>

On Sun, 2015-06-14 at 11:08 +0100, Dibyendu Majumdar wrote:
> I am still trying to get the lvalue / rvalue concepts so that I know
> exactly what to use when.
> 
> I have struct with a pointer member.
> 
> struct X {
>  struct Y *base;
> };
> 
> Now this pointer base can be updated while the function is running so
> I need the value of the pointer refreshed (loaded) whenever it can
> potentially change. In LLVM I emit explicit load instructions which
> are then optimized so that any redundant loads are deleted. What would
> be the equivalent method here? Should I just use a rvalue reference?

Just use an gcc_jit_rvalue *: it represents an expression tree.

> Will this be automatically refreshed?

Yes.  libgccjit will generate code for the expression tree.

In theory the generated code will re-evaluate the full expression tree
each time, but some of that code may get optimized away if you've got
optimizations enabled, but only when the optimizer can "know" that it is
safe.  Typically if you have a pointer chain to something that's visible
outside of local scope then the optimizer can't know whether or not
something else is writing to the ptr, so the generated code has to
re-read it each time.

> Should I use a local variable
> and assign the value of the base pointer to it explicitly (i.e.
> similar to explicit load) ?

That's worth doing if you know more than the optimizer can about when
the value can change (e.g. if you're calling some function, and know
that the value can't be changed by it, whereas the optimizer has to
assume that it might touch it).

Local variables are much more "optimizable" than accesses to memory,
especially memory that might get touched in a function call.  GCC
internally uses an SSA representation and can do a lot of
simplifications to uses of local vars.

It may be worth reading:
https://gcc.gnu.org/onlinedocs/jit/intro/tutorial04.html#behind-the-curtain-how-does-our-code-get-optimized

and playing with:

gcc_jit_context_set_bool_option (state.ctxt,
                                 GCC_JIT_BOOL_OPTION_DUMP_EVERYTHING,
                                 1);
gcc_jit_context_set_bool_option (state.ctxt,
                                 GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES,
                                 1);

to see what happens to the code you supply.

> Thanks and Regards

Hope the above makes sense
Dave


  reply	other threads:[~2015-06-15  0:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-01  0:00 Dibyendu Majumdar
2015-01-01  0:00 ` David Malcolm [this message]
2015-01-01  0:00   ` Dibyendu Majumdar

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=1434328706.3192.17.camel@surprise \
    --to=dmalcolm@redhat.com \
    --cc=jit@gcc.gnu.org \
    --cc=mobile@majumdar.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).