From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42165 invoked by alias); 15 Jun 2015 19:39:32 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 41490 invoked by uid 89); 15 Jun 2015 19:39:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.7 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-yk0-f182.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gq5OM4YqEp9sZmO+CmwbtSqW4x+3W72RtLqu+Jbp1F0=; b=SYZic5B4xYHvJMEahTh/FOS3lq3MrLYX4L6JEUZaiY2npnKeAO3ME62gly6kqGNiSB 3UNTbqUGcW1mpQUAQpPmv9p5BgV/zbJiEXpJlSYOYYUinfG4mUWO8OpvAZRc/7gDJ+Np i5DHmOEEQmIk2ms6XPG32vK5QMU7DcgGNrZ8kS1BsCEa6AEDESJn/8k7gz91wBPM48tq lIrDQn49UtIN6dU5UnS/UE4DVOrXNbQk7vaVw4PZe+0U5EpgUXtr9C+dIyp408lhDSPn FrbjKPr+0JHD/PJ2xD6pa/DL0gq7Xsz4maj80D8/8ofJjLBkIBUuQbpqVUtRTVbK/cM6 zmXQ== X-Gm-Message-State: ALoCoQnYcSj3lSimm5z+XsDVHY8c+wkJ3jx/Nt+KorMmMa3hvNyemIMYjFU0lPRsYaLch5pYidbr MIME-Version: 1.0 X-Received: by 10.170.56.78 with SMTP id 75mr31382101yky.109.1434397168966; Mon, 15 Jun 2015 12:39:28 -0700 (PDT) In-Reply-To: <1434328706.3192.17.camel@surprise> References: <1434328706.3192.17.camel@surprise> Date: Thu, 01 Jan 2015 00:00:00 -0000 Message-ID: Subject: Re: lvalues and rvalues From: Dibyendu Majumdar To: David Malcolm Cc: jit@gcc.gnu.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-q2/txt/msg00069.txt.bz2 On 15 June 2015 at 01:38, David Malcolm 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