From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17541 invoked by alias); 23 May 2010 13:36:45 -0000 Received: (qmail 17532 invoked by uid 22791); 23 May 2010 13:36:44 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 23 May 2010 13:36:38 +0000 Received: (qmail 18075 invoked from network); 23 May 2010 13:36:37 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 May 2010 13:36:37 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.69) (envelope-from ) id 1OGBM3-00021Y-PV; Sun, 23 May 2010 13:36:35 +0000 Date: Sun, 23 May 2010 19:09:00 -0000 From: "Joseph S. Myers" To: Steven Bosscher cc: Duncan Sands , gcc@gcc.gnu.org Subject: Re: Where does the time go? In-Reply-To: Message-ID: References: <4BF58AE0.3090103@redhat.com> <4BF5A181.5090003@free.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-05/txt/msg00446.txt.bz2 On Thu, 20 May 2010, Steven Bosscher wrote: > think, the tree-like representation. If you have an instruction like > (set (a) (b+c)) you could have, at the simples, three integers (insn > uid, basic block, instruction code) and three pointers for operands. > In total, on a 64 bits host: 3*4+3*8 = 36 bytes. (Plus four bytes padding for alignment.) > An RTL instruction of that form, assuming all operands are registers, > is 6*sizeof(struct rtx_def) = 6*48 = 288 bytes, give or take a few. > Those 6 rtx'en are for: > > 1. insn > 2. set > 3. set_dest operand > 4. set_source: a plus > 5. source operand 1 > 6. source operand 2 > > All in all, perhaps not the most efficient representation for memory > foot print, and the pointer chasing probably doesn't help (cache!). > But changing it is a lot more difficult than the GIMPLE tuples > project. I don't think it can be done. I don't see any reason technically why it can't be done. There would be several large projects, certainly, and nontrivial work in actually producing a design for conversion, but there are also clear incremental steps, such as static typing of some different kinds of RTL and moving to more specific accessors for parts of an RTX in place of generic ones such as XEXP used at present. If it can't be done then that would be more for economic reasons - no-one benefiting enough from the change, potential benefits being gained more cheaply in other ways - than because of intrinsic technical obstacles. -- Joseph S. Myers joseph@codesourcery.com