From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19383 invoked by alias); 12 Feb 2004 12:48:35 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19376 invoked from network); 12 Feb 2004 12:48:34 -0000 Received: from unknown (HELO smtp.uk.superh.com) (193.128.105.170) by sources.redhat.com with SMTP; 12 Feb 2004 12:48:34 -0000 Received: from sh-uk-ex01.uk.w2k.superh.com (sh-uk-ex01 [192.168.16.17]) by smtp.uk.superh.com (8.12.10/8.12.10) with ESMTP id i1CCmAAA001889; Thu, 12 Feb 2004 12:48:11 GMT Received: from linsvr1.uk.superh.com ([192.168.16.50]) by sh-uk-ex01.uk.w2k.superh.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 12 Feb 2004 12:49:39 +0000 Received: (from renneckej@localhost) by linsvr1.uk.superh.com (8.11.6/8.11.6) id i1CCm8o08759; Thu, 12 Feb 2004 12:48:08 GMT From: Joern Rennecke Message-Id: <200402121248.i1CCm8o08759@linsvr1.uk.superh.com> Subject: Re: [RFA (revised)] sh-sim, expand the opcode table To: msnyder@redhat.com (Michael Snyder) Date: Thu, 12 Feb 2004 12:48:00 -0000 Cc: joern.rennecke@superh.com (Joern Rennecke), amylaar@fairadsl.co.uk (Joern Rennecke), gdb-patches@sources.redhat.com In-Reply-To: <402A81B9.6080009@redhat.com> from "Michael Snyder" at Feb 11, 2004 11:25:45 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Feb 2004 12:49:39.0202 (UTC) FILETIME=[AD3E8620:01C3F166] X-Scanned-By: MIMEDefang 2.39 X-SW-Source: 2004-02/txt/msg00316.txt.bz2 > Imprecisely speaking, they did not seem to make any difference at all. > The number of new insns is actually not that great -- they only bring > the switch statement up to about 290 cases. OK. I think we can live with the 1% slowdown then, considering that we expand the expressiveness of the jump table in a way that should be good for several decades. When I initailly added the sh-dsp stuff, the slowdown was much worse, which is why I then spent some time optimizing the simulator till the performance was better than it was before the sh-dsp support was added. FWIW, we don't actually benefit much from technological progress here to mitigate slowdowns, because we already have rising numbers of multilibs, compiler options, and sheer volume of tests to go through, which is why simulator performance is still more critical than gcc build times for total regression test time.