From mboxrd@z Thu Jan 1 00:00:00 1970 From: Randolph Chung Subject: Re: [parisc-linux] [gcc] should we teach gcc some new tricks? Date: Thu, 24 Mar 2005 15:55:07 -0800 Message-ID: <20050324235501.GL2485@tausq.org> References: <20050324223346.GE29361@colo.lackof.org> <200503242334.j2ONYgHV007051@hiauly1.hia.nrc.ca> Reply-To: Randolph Chung Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: parisc-linux@lists.parisc-linux.org To: John David Anglin Return-Path: In-Reply-To: <200503242334.j2ONYgHV007051@hiauly1.hia.nrc.ca> List-Id: parisc-linux developers list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: parisc-linux-bounces@lists.parisc-linux.org > Not good. This is from libgcc. I see that the muldi3 expander is > disabled when we disable FP regs. I'm not sure why but it doesn't > seem right. Using the expander, would cause the use of the millicode > routine when FP regs are disabled. We *do not* disable fpregs in the kernel. We would like to though. The problem is precisely libgcc - even if we compile the kernel with --disable-fpregs, millicode calls generated by gcc will still use fpregs. One proposal that has been talked about before is if we can compile a version of the millicode lib that uses limited fpregs range and compile the kernel using this new option that Dave is talking about, then we will be able to get by using a (much) smaller subset of fp regs and we won't have to save/restore them in the kernel. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux