From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Subject: Re: [PATCH 4/5] aic7xxx: teach aicasm to not emit unused debug code/data Date: Mon, 28 Apr 2008 09:18:12 +0200 Message-ID: <48157A34.1080600@suse.de> References: <200804250432.16943.vda.linux@googlemail.com> <200804250441.43480.vda.linux@googlemail.com> <4811D635.4020904@suse.de> <200804260242.45192.vda.linux@googlemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from cantor2.suse.de ([195.135.220.15]:57889 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1765397AbYD1HSO (ORCPT ); Mon, 28 Apr 2008 03:18:14 -0400 In-Reply-To: <200804260242.45192.vda.linux@googlemail.com> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Denys Vlasenko Cc: linux-scsi@vger.kernel.org Denys Vlasenko wrote: > Hi Hannes, >=20 > On Friday 25 April 2008 15:01, Hannes Reinecke wrote: >>> Add "dont_generate_debug_code" syntax handling to aicasm_gram.y >>> >>> aic79xx.reg, aic7xxx.reg: add dont_generate_debug_code keyword >>> for registers which are never referenced by the driver. >>> >>> aicasm.c, aicasm_symbol.[ch]: don't emit code for those regs; >>> also add "const" keyword to generated code in few places. >>> >>> Signed-off-by: Denys Vlasenko >> No. >> Adding a symbol to each and every register definition >> which has to be hand-crafted anyway is not the correct way. >> >> I would prefer this: Add a 'count' variable to each symbol >> which gets increased every time the symbol is referenced. >> And then modify the register definition to include counts >> for symbols which are referenced from the source code only >> and not from the sequencer code. >=20 > To be honest, I don't understand how your patch achieves it. > I am not familiar enough with the way aicasm machinery works. >=20 Ach, that's just straight lex/yacc stuff :-) No, seriously, it's not that hard to understand. Basically aicasm builds a list of all used symbols, then builds a reference table on to of that list whenever a symbol is referenced in the actual code, and then does some cleanup etc. to be able to put out proper sequencer code. So the trick here is that we can add a 'count' field to the underlying symbol table, which will be incremented everytime this symbol is referenced by the sequencer code. Nice and clean. In theory. >> This will give us an automatic usage count for the symbols >> with only minimal hand-crafting. >=20 > I tested your patches atop my patches 1,2,3 versus my patches > 1...5, and versus original scsi-misc-2.6-2008_04_15. > They build successfully, although they result in bigger code: >=20 [ .. ] >=20 > As compared to my patches there are more than 20 kb > of unused code. My patches can be improved too. > "make namespacecheck" shows unused functions' names. >=20 Yes, I know. There is a snag to the above reasoning: Symbols are not only referenced by the sequencer code, but also by the actual driver. And there are symbols which are referenced from the driver source code only, not from the sequencer. So aicasm will _not_ catch those. That's why I added to 'count' field explicitely to some symbols; these are referenced from the source code only. But now we're facing another problem: Those symbols referenced from the sequencer code only will in most cases _not_ be printed via the autogenerated _print functions. So what we really need to do here to do this properly is to write a preprocessor, which checks the _used_=20 *_print() functions in the source code and generates the aic7*xx_reg_print.c file on the fly. And remove this code from aicasm entirely. But this really might be considered a bit of an overkill. But I wouldn't stand in the way of anyone trying to do so. Cheers, Hannes --=20 Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg GF: Markus Rex, HRB 16746 (AG N=C3=BCrnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html