From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122104 invoked by alias); 15 Jul 2015 22:47:55 -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 122094 invoked by uid 89); 15 Jul 2015 22:47:55 -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=-0.8 required=5.0 tests=AWL,BAYES_05,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_05,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-f170.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:content-type; bh=Q32FYP8epIiAgHxdfv4dFowaI6rnK0t1FhklO8UdBsk=; b=Eg2Tr7AMO79CnrvA5tAXlTWQdHbF7PcQGv7DANOfwvnIrKbY2GOapexZc+3k2XaXHl nNgSouRS/Hgqwobm6OV0/RWGay3xAIxNcabavrhtDhQt2w74p2qMn5rxlGDADOcb6JPK mNY5idgzFqhZ7WWF7iUuZVlYfWw+nXz+vB43iSQzXiysAoN1M15SFRTXiJtE0+uHnXHh DOPCErrQeu09EaZBFoPyFzwRCn2ArYamrD17zvtvPjvHYNyXOPCWNKCLMKDus+1NwZog DBoHvcz9a0RYs3KtHCsIpJMAewH6CT4Sb2Om/9W7frH5OOIFHQ1De98ihLgRtg5+0Z4t VmSQ== X-Gm-Message-State: ALoCoQlQNIUkfftmypp5BzGw/08OR+U9K0YB8yQsrIZlD/7blCk1N7x+ThKNuAkxprCG1Slpgmay MIME-Version: 1.0 X-Received: by 10.13.229.198 with SMTP id o189mr6786997ywe.108.1437000471582; Wed, 15 Jul 2015 15:47:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 01 Jan 2015 00:00:00 -0000 Message-ID: Subject: Re: Potential performance issue From: Dibyendu Majumdar To: jit@gcc.gnu.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-q3/txt/msg00097.txt.bz2 On 15 July 2015 at 20:47, Dibyendu Majumdar wrote: >> As you know currently I take the address of a Lua stack value and then >> use the pointer to manipulate the value. This is hangover from the >> LLVM port as there it has to be a pointer. But in the libgccjit world, >> we actually do not need the pointer unless the pointer needs to be >> passed to a function. So most of the time we can just work off the >> value array directly. >> >> That is instead of: >> >> (&base[1])->value.tt_ >> >> I can just use >> base[1]->value.tt_ > > I meant base[1].value.tt_ above (sorry for the typo!) > >> >> I was hoping that this might help performance somewhat as presumably a >> pointer (going by your change to get_address) may not be optimisable. >> To my surprise however the performance dropped by half after the >> change. So of course I have not committed this change. >> It turns out that I had the build set to Debug build. This threw me as the Ravi build setting should have no impact on the JIT compiler (as it has its own setting) so not sure why the performance was degraded. Apologies for the false alarm. Regards Dibyendu