From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24957 invoked by alias); 26 Mar 2004 02:19:50 -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 24850 invoked from network); 26 Mar 2004 02:19:49 -0000 Received: from unknown (HELO mms3.broadcom.com) (63.70.210.38) by sources.redhat.com with SMTP; 26 Mar 2004 02:19:49 -0000 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Thu, 25 Mar 2004 18:19:44 -0800 X-Server-Uuid: 8D569F9F-42CF-4602-970D-AACC4BD5D310 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA12724; Thu, 25 Mar 2004 18:19:02 -0800 (PST) Received: from ldt-sj3-010.sj.broadcom.com (ldt-sj3-010 [10.21.64.10]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id i2Q2JXov022966; Thu, 25 Mar 2004 18:19:34 -0800 (PST) Received: (from cgd@localhost) by ldt-sj3-010.sj.broadcom.com ( 8.11.6/8.9.3) id i2Q2JXS14774; Thu, 25 Mar 2004 18:19:33 -0800 X-Authentication-Warning: ldt-sj3-010.sj.broadcom.com: cgd set sender to cgd@broadcom.com using -f To: cagney@gnu.org cc: "Richard Sandiford" , gdb-patches@sources.redhat.com Subject: Re: [rfa/mips] Second go at vr5500 hilo hazard fix References: <87oequw5xw.fsf@redhat.com> <87znadvpr7.fsf@redhat.com> <406359BA.9000302@gnu.org> <40637918.5000708@gnu.org> From: cgd@broadcom.com Date: Fri, 26 Mar 2004 02:19:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-WSS-ID: 6C7D4CCA2IW888263-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00649.txt.bz2 At Fri, 26 Mar 2004 00:28:27 +0000 (UTC), "Andrew Cagney" wrote: > > At Thu, 25 Mar 2004 17:14:18 -0500, Andrew Cagney wrote: > > > >>> Look at it this way, if the igen mechanism is used, gcc is able to > >>> eliminate everything :-) > > In the case of a single-architecture sim (i.e., not 'multi', then > > yes), GCC will automatically eliminate the test. > > In the case of a multiple-architecture sim, it won't. > > It still does (or at least can), trust me :-) err, sorry, i think i misquoted you. What I meant to quote was: > If there's another way of achieving the same effect, I'm interested. I know that doing multi-arch checking entirely with different machine attributes will eliminate the diff. (actually, in that case, it's still "mostly," now that i think about it. in multiple-MIPS-arch-capable sims, it still moves moves the arch check up into sim_engine_run.) cgd