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

On 15 June 2015 at 01:38, David Malcolm <dmalcolm@redhat.com> wrote:
> 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).
>

In the Lua interpreter the code does this exactly. However I set the
variable on every instruction I compile on the assumption that if the
variable is not involved in an external call between bytecodes and
there are no steps that modify the value stored in the variable then
the optimizer will do away with the redundant assignments. This seems
to be true in LLVM once appropriate aliasing metadata is provided. I
would hope that the gcc optimizer will do the same.

Setting the variables manually is problematic due to the unforeseen
interaction of basic blocks ... I would rather err on the side of
correctness. I did consider doing this manually initially but gave up
the idea when I found I could not reason about the way the blocks
would interact and what it would do to the assumptions I made.

Regards

      reply	other threads:[~2015-06-15 19:39 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
2015-01-01  0:00   ` Dibyendu Majumdar [this message]

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=CACXZuxcaFsTf-BssK4iFP-Hwe-3akvjTW_EWVrjU_wa4HkW+Zg@mail.gmail.com \
    --to=mobile@majumdar.org.uk \
    --cc=dmalcolm@redhat.com \
    --cc=jit@gcc.gnu.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 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).