From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19426 invoked by alias); 26 Mar 2007 05:50:29 -0000 Received: (qmail 19416 invoked by uid 22791); 26 Mar 2007 05:50:28 -0000 X-Spam-Check-By: sourceware.org Received: from nz-out-0506.google.com (HELO nz-out-0506.google.com) (64.233.162.238) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 26 Mar 2007 06:50:25 +0100 Received: by nz-out-0506.google.com with SMTP id m7so1352190nzf for ; Sun, 25 Mar 2007 22:50:23 -0700 (PDT) Received: by 10.114.153.18 with SMTP id a18mr2494260wae.1174888222564; Sun, 25 Mar 2007 22:50:22 -0700 (PDT) Received: by 10.114.255.13 with HTTP; Sun, 25 Mar 2007 22:50:22 -0700 (PDT) Message-ID: Date: Mon, 26 Mar 2007 05:50:00 -0000 From: "Chuan-Hua Chang" To: "Dave Brolley" Subject: Re: generated decoder code question Cc: "Frank Ch. Eigler" , cgen@sourceware.org In-Reply-To: <4603DD87.9090002@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070323113053.GR27273@redhat.com> <4603DD87.9090002@redhat.com> Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00070.txt.bz2 > > Please point out any cases where the test is not needed and I will see > if I can eliminate it in those cases. > Using sid/component/cgen-cpu/mt/mt-decode.cxx as an example: --------------------------------------------------------------------------------------------- void mt_scache::decode (mt_cpu* current_cpu, PCADDR pc, mt_insn_word base_insn, mt_insn_word entire_insn) { /* Result of decoder. */ MT_INSN_TYPE itype; { mt_insn_word insn = base_insn; { unsigned int val = (((insn >> 24) & (255 << 0))); switch (val) { case 0 : if ((entire_insn & 0xff000fff) == 0x0) { itype = MT_INSN_ADD; mt_extract_sfmt_add (this, current_cpu, pc, base_insn, entire_insn); goto done; } itype = MT_INSN_X_INVALID; mt_extract_sfmt_empty (this, current_cpu, pc, base_insn, entire_insn); goto done; case 1 : if ((entire_insn & 0xff000000) == 0x1000000) { itype = MT_INSN_ADDI; mt_extract_sfmt_addi (this, current_cpu, pc, base_insn, entire_insn); goto done; } itype = MT_INSN_X_INVALID; mt_extract_sfmt_empty (this, current_cpu, pc, base_insn, entire_insn); goto done; case 2 : if ((entire_insn & 0xff000fff) == 0x2000000) { itype = MT_INSN_ADDU; mt_extract_sfmt_addu (this, current_cpu, pc, base_insn, entire_insn); goto done; } itype = MT_INSN_X_INVALID; mt_extract_sfmt_empty (this, current_cpu, pc, base_insn, entire_insn); goto done; case 3 : if ((entire_insn & 0xff000000) == 0x3000000) { itype = MT_INSN_ADDUI; mt_extract_sfmt_addui (this, current_cpu, pc, base_insn, entire_insn); goto done; } itype = MT_INSN_X_INVALID; mt_extract_sfmt_empty (this, current_cpu, pc, base_insn, entire_insn); goto done; case 4 : if ((entire_insn & 0xff000fff) == 0x4000000) { itype = MT_INSN_SUB; mt_extract_sfmt_add (this, current_cpu, pc, base_insn, entire_insn); goto done; } itype = MT_INSN_X_INVALID; mt_extract_sfmt_empty (this, current_cpu, pc, base_insn, entire_insn); goto done; case 5 : if ((entire_insn & 0xff000000) == 0x5000000) { itype = MT_INSN_SUBI; mt_extract_sfmt_addi (this, current_cpu, pc, base_insn, entire_insn); goto done; } itype = MT_INSN_X_INVALID; mt_extract_sfmt_empty (this, current_cpu, pc, base_insn, entire_insn); goto done; --------------------------------------------------------------------------------------------------- The top level switch/case statement tests the upper 8 bits of the instruction ((>> 24) & 255). For case 0, it is true that additional lower 12 bits are being tested (& 0xff000fff). However, for case 1, no additional bits are being tested (& 0xff000000), this is where the redundancy comes in. I would expect CGEN to detect this case and not generate unnecessary IF checking here. (e.g similar to M32R code in the CGEN release.) >> >> When looking at the M32R decode function, the IF-statement is absent >> from the decoder code. This lets me wonder that if there is a way to >> remove this redundant IF-statement check in the CGEN flow. >> >This is likely a case where all of the decodable bits have already been >tested in reaching that particular case. > May I ask that if the released M32R code is generated by the current CGEN utils-sim.scm file or generated by another version or hand-edited to remove the IF checking statement mentioned in my question? I am asking this since from the the "-gen-decode-insn-entry" function I do not see any conditional construct to control the generation of the IF checking code. It seems that the IF checking code is always generated. I have also re-generated the M32R simulator to confirm my guess, and the newly-generated M32R decode function DOES have the IF checking statement now. Am I missing something? > >Do you have a sense of how frequently such a test is completely >redundant, and how much additional time this test takes? > For high locality code, the decode function may not be invoked that frequently, but for low locality code, the decode function will be invoked a lot more often. it seems that this kind of redundancy should be made as few as possible. Thanks for your help.