From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20369 invoked by alias); 24 Jun 2005 16:09:56 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 20354 invoked by uid 22791); 24 Jun 2005 16:09:50 -0000 Received: from topconrd.ru (HELO TopconRD.RU) (62.105.138.7) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 24 Jun 2005 16:09:50 +0000 Received: from osv.topcon.com (ttc.topconrd.ru [62.105.138.5]) by TopconRD.RU (8.12.3/8.12.3/Debian-6.6) with ESMTP id j5OG9iL0010852; Fri, 24 Jun 2005 20:09:44 +0400 To: Andrew Pinski Cc: gcc@gcc.gnu.org Subject: Re: How to replace -O1 with corresponding -f's? References: <878y159mhr.fsf@osv.topcon.com> <17078.52477.408454.106678@zapata.pink> <44a7432710d6ca83042f60c9fbab58d9@physics.uc.edu> <87zmtl84eo.fsf@osv.topcon.com> <87r7ex82ur.fsf@osv.topcon.com> X-attribution: osv From: Sergei Organov Date: Fri, 24 Jun 2005 16:09:00 -0000 In-Reply-To: Message-ID: <871x6r7n3w.fsf@osv.topcon.com> User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-06/txt/msg01023.txt.bz2 Andrew Pinski writes: > On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote: > > > Andrew Pinski writes: > > > >> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote: > >> > >>> so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1 > > >> > >>> is turned on. Seems to be something at tree-to-RTX conversion time. > >>> Constant folding? > >> > >> No, it would mean that the target says that this is not a small data. > >> Also try it with the following code and you will see there is no difference: > > >> > >> double osvf() { return 314314314; } > > > > There is no difference in the sense that here both -O0 and -O1 behave > > roughly the same. So the problem is with detecting "smallness" for true > > constants by the target, right? > > I think the bug is in rs6000_elf_in_small_data_p but since I have not > debuged it yet I don't know for sure. No, the bug is not there as the function is never called for this constant. The constant is generated in RTL and thus can't be passed to this routine expecting tree. The debugging shows that the constant in question first appears within small_data_operand(op, mode) in the form: op = (symbol_ref/u:SI (".LC0") [flags 0x2]) mode = DFmode without the SYMBOL_FLAG_SMALL set resulting in returning 0 by the routine. We can naively try to add code at this point that checks GET_MODE_SIZE(mode) and return 1 if the size is less than or equal to the limit for sdata2 (=g_switch_value). However this attempt is not satisfactory as later this same constant appears at the same place as: op = (symbol_ref/u:SI (".LC0") [flags 0x2]) mode = SImode(!) Now, provided g_switch_value is set to 4 (it's default value is 8), we would return 0 in the first case and 1 in the second case for the same constant! The resulting assembly is weird. The latter appearance of the constant with mode=SImode is due to call to memory_address(DFMode, op) that calls force_reg(Pmode(=SImode), op) #0 small_data_operand (op=0x401e2730, mode=SImode) at ../../../gcc/gcc/config/rs6000/rs6000.c:2358 #1 0x08704fb0 in rs6000_emit_move (dest=0x401e2740, source=0x401e2730, mode=SImode) at ../../../gcc/gcc/config/rs6000/rs6000.c:3720 #2 0x0852cfb8 in gen_movsi (operand0=0x401e2740, operand1=0x401e2730) at ../../../gcc/gcc/config/rs6000/rs6000.md:7410 #3 0x08430c3c in emit_move_insn_1 (x=0x401e2740, y=0x401e2730) at ../../../gcc/gcc/expr.c:3086 #4 0x08431020 in emit_move_insn (x=0x401e2740, y=0x401e2730) at ../../../gcc/gcc/expr.c:3164 #5 0x08410891 in force_reg (mode=SImode, x=0x401e2730) at ../../../gcc/gcc/explow.c:607 #6 0x0841029b in memory_address (mode=DFmode, x=0x401e2730) at ../../../gcc/gcc/explow.c:409 .... At this stage I gave up trying to solve this puzzle. Any ideas how to fix that? -- Sergei.