From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15990 invoked by alias); 28 Nov 2007 13:36:54 -0000 Received: (qmail 15938 invoked by uid 48); 28 Nov 2007 13:36:41 -0000 Date: Wed, 28 Nov 2007 13:36:00 -0000 Message-ID: <20071128133641.15937.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/34250] ICE in find_constant_pool_ref In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "uweigand at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg02774.txt.bz2 ------- Comment #3 from uweigand at gcc dot gnu dot org 2007-11-28 13:36 ------- Hi Michael, the problem is that there is an implicit assumption throughout the code that you can have at most one pool constant per instruction. For example, the pool size / splitting heuristics assume that. I think with your patch as is, you can find examples where it will attempt to add 2 constants to the current pool chunk even though it only has room for 1 left. This could probably be fixed by reworking some of the heuristics (e.g. check *first* how many constants an insn will require, and start up a new pool early if required). But that can be a bit tricky ... What fundamentally cannot be fixed is the extreme case where the single instruction uses so many constants that they don't fit into a pool chunk even by themselves. We can only reload the base register to point to a different chunk once before every insn. Can you elaborate why this occurs in "normal" code (without inline asm)? -- uweigand at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |uweigand at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34250