* How to replace -O1 with corresponding -f's? @ 2005-06-20 13:40 Sergei Organov 2005-06-20 14:04 ` Andrew Haley ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Sergei Organov @ 2005-06-20 13:40 UTC (permalink / raw) To: gcc Hi, Using gcc compiled from gcc-4_0-branch, in an attempt to see which particular optimization option makes my test case to be mis-optimized, I try to replace -O1 (which toggles on the problem) with corresponding set of -fxxx optimization options. I first compile my code like this: gcc -v -save-temps -fverbose-asm -O1 -o const.o -c const.c then merge the cc1 command that gcc invokes to compile the preprocessed source (as gcc doesn't seem to pass some of -f forward to cc1) with the entire list of options taken from resulting const.s file (found at the line " # options enabled: ..." and further), and compile using this. In the resulting const.s file there are 2 problems: 1. "options enabled" output almost matches those from the initial (-O1) invocation, but -floop-optimize is missing though it does exist in the "options passed" output. 2. The resulting assembly is different from what I get with -O1 and doesn't contain the mis-optimization I'm trying to debug though it doesn't seem to have anything to do with loops. For reference, the code I'm trying to compile is: extern double const osv; double const osv = 314314314; double osvf() { return osv; } Am I doing something stupid or what? How one finds out what optimization pass misbehaves? -- Sergei. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-20 13:40 How to replace -O1 with corresponding -f's? Sergei Organov @ 2005-06-20 14:04 ` Andrew Haley 2005-06-20 14:26 ` Andrew Pinski 2005-06-20 14:28 ` Sergei Organov 2005-06-20 14:25 ` Scott Robert Ladd 2005-06-20 14:35 ` Andrew Pinski 2 siblings, 2 replies; 17+ messages in thread From: Andrew Haley @ 2005-06-20 14:04 UTC (permalink / raw) To: Sergei Organov; +Cc: gcc Sergei Organov writes: > Hi, > > Using gcc compiled from gcc-4_0-branch, in an attempt to see which > particular optimization option makes my test case to be mis-optimized, I > try to replace -O1 (which toggles on the problem) with corresponding set > of -fxxx optimization options. In general you can't do this. You can turn some optimization passes off, though. > How one finds out what optimization pass misbehaves? Look at the dumps. If you use the gcc option -da you'll get a full set of RTL dump files. Andrew. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-20 14:04 ` Andrew Haley @ 2005-06-20 14:26 ` Andrew Pinski 2005-06-20 14:55 ` Sergei Organov 2005-06-20 14:28 ` Sergei Organov 1 sibling, 1 reply; 17+ messages in thread From: Andrew Pinski @ 2005-06-20 14:26 UTC (permalink / raw) To: Andrew Haley; +Cc: gcc, Sergei Organov On Jun 20, 2005, at 10:04 AM, Andrew Haley wrote: >> How one finds out what optimization pass misbehaves? > > Look at the dumps. If you use the gcc option -da you'll get a full > set of RTL dump files. And -fdump-tree-all for the tree dumps. Thanks, Andrew Pinski ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-20 14:26 ` Andrew Pinski @ 2005-06-20 14:55 ` Sergei Organov 2005-06-20 15:01 ` Andrew Pinski 0 siblings, 1 reply; 17+ messages in thread From: Sergei Organov @ 2005-06-20 14:55 UTC (permalink / raw) To: Andrew Pinski; +Cc: gcc Andrew Pinski <pinskia@physics.uc.edu> writes: > On Jun 20, 2005, at 10:04 AM, Andrew Haley wrote: > >> How one finds out what optimization pass misbehaves? > > > > Look at the dumps. If you use the gcc option -da you'll get a full > > set of RTL dump files. > > And -fdump-tree-all for the tree dumps. The last const.c.t69.final_cleanup is exactly the same in both cases and doesn't have any useful information anyway: ;; Function osvf (osvf) osvf () { <bb 0>: return 3.14314314e+8; } In fact, at the RTL level the difference is that non-optimized code (insn 8 6 9 1 (set (reg:DF 118 [ D.1144 ]) (mem/u/i:DF (symbol_ref:SI ("osv") [flags 0x6] <var_decl 0x401ab32c osv> (nil)) (insn 9 8 10 1 (set (reg:DF 119 [ <result> ]) (reg:DF 118 [ D.1144 ])) -1 (nil) (nil)) gets replaced with "optimized" one: (insn 10 9 11 1 (set (reg:SI 121) (high:SI (symbol_ref/u:SI ("*.LC0") [flags 0x2]))) -1 (nil) (nil)) (insn 11 10 12 1 (set (reg/f:SI 120) (lo_sum:SI (reg:SI 121) (symbol_ref/u:SI ("*.LC0") [flags 0x2]))) -1 (nil) (expr_list:REG_EQUAL (symbol_ref/u:SI ("*.LC0") [flags 0x2]) (nil))) (insn 12 11 13 1 (set (reg:DF 118 [ <result> ]) (mem/u/i:DF (reg/f:SI 120) [0 S8 A64])) -1 (nil) (expr_list:REG_EQUAL (const_double:DF 3.14314314e+8 [0x0.95e0725p+29]) (nil))) 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? -- Sergei. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-20 14:55 ` Sergei Organov @ 2005-06-20 15:01 ` Andrew Pinski 2005-06-20 15:29 ` Sergei Organov 0 siblings, 1 reply; 17+ messages in thread From: Andrew Pinski @ 2005-06-20 15:01 UTC (permalink / raw) To: Sergei Organov; +Cc: gcc 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; } Thanks, Andrew Pinski ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-20 15:01 ` Andrew Pinski @ 2005-06-20 15:29 ` Sergei Organov 2005-06-20 15:36 ` Andrew Pinski 0 siblings, 1 reply; 17+ messages in thread From: Sergei Organov @ 2005-06-20 15:29 UTC (permalink / raw) To: Andrew Pinski; +Cc: gcc Andrew Pinski <pinskia@physics.uc.edu> 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? But even then, if I fix that, there still will be a problem that for given platform there doesn't seem to be a single reason to replace double const osv = 314314314; double osvf() { return osv; } with double const osv = 314314314; double const .LC0 = 314314314; double osvf() { return .LCO; } where .LCO is compiler-generated symbol. And the latter does have something to do with const folding, doesn't it? -- Sergei. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-20 15:29 ` Sergei Organov @ 2005-06-20 15:36 ` Andrew Pinski 2005-06-20 15:58 ` Sergei Organov ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Andrew Pinski @ 2005-06-20 15:36 UTC (permalink / raw) To: Sergei Organov; +Cc: gcc On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote: > Andrew Pinski <pinskia@physics.uc.edu> 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. Could you file a bug? This is a target bug. -- Pinski ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-20 15:36 ` Andrew Pinski @ 2005-06-20 15:58 ` Sergei Organov 2005-06-21 9:55 ` Michael Meissner 2005-06-20 17:18 ` Sergei Organov 2005-06-24 16:09 ` Sergei Organov 2 siblings, 1 reply; 17+ messages in thread From: Sergei Organov @ 2005-06-20 15:58 UTC (permalink / raw) To: Andrew Pinski; +Cc: gcc Andrew Pinski <pinskia@physics.uc.edu> writes: > On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote: > > > Andrew Pinski <pinskia@physics.uc.edu> 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. > > Could you file a bug? This is a target bug. Yeah, and I've reported it rather long ago against gcc-3.3 (PR 9571). That time there were 3 problems reported in the PR of which only the first one seems to be fixed (or are the rest just re-appeared in 4.0?). I think PR 9571 is in fact regression with respect to 2.95.x despite the [wrong] comments: ------- Additional Comment #5 From Franz Sirl 2003-06-17 15:31 [reply] ------- r0 is used as a pointer to sdata2, this is a bug, it should be r2. And since only r2 is initialized in the ecrt*.o files, how can this work? Besides that, even if you initialize r0 manually, it is practically clobbered in about every function. ------- Additional Comment #6 From Mark Mitchell 2003-07-20 00:52 [reply] ------- Based on Franz's comments, this bug is not really a regression at all. I've therefore removed the regression tags. that I've tried to explain in my comment #7. I don't think I need to file yet another PR in this situation, right? -- Sergei. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-20 15:58 ` Sergei Organov @ 2005-06-21 9:55 ` Michael Meissner 2005-06-21 12:49 ` Sergei Organov 0 siblings, 1 reply; 17+ messages in thread From: Michael Meissner @ 2005-06-21 9:55 UTC (permalink / raw) To: gcc On Mon, Jun 20, 2005 at 07:57:17PM +0400, Sergei Organov wrote: > Andrew Pinski <pinskia@physics.uc.edu> writes: > > > On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote: > > > > > Andrew Pinski <pinskia@physics.uc.edu> 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. > > > > Could you file a bug? This is a target bug. > > Yeah, and I've reported it rather long ago against gcc-3.3 (PR 9571). > That time there were 3 problems reported in the PR of which only the > first one seems to be fixed (or are the rest just re-appeared in 4.0?). > > I think PR 9571 is in fact regression with respect to 2.95.x despite the > [wrong] comments: > > ------- Additional Comment #5 From Franz Sirl 2003-06-17 15:31 [reply] ------- > > r0 is used as a pointer to sdata2, this is a bug, it should be r2. And > since only r2 is initialized in the ecrt*.o files, how can this work? > Besides that, even if you initialize r0 manually, it is practically > clobbered in about every function. It's been a long time since I've hacked the PowerPC, but IIRC the instruction set, a base register of '0' does not mean r0, but instead it means use 0 as the base address. Every place that uses a base register should use the register class 'b' (BASE_REGS) instead of 'r' (GENERAL_REGS), which excludes r0 from being considered. Under the 32-bit eABI calling sequence, you have three small data areas: The small data area that r2 points to (.sdata/.sbss). The small data area that r13 points to (.sdata2/.sbss2). The small data area centered around location 0 (ie, small positive addresses, and the most negative addresses). I don't recall that we had special sections for this, since for many embedded apps, they couldn't allocate to those addresses. For these relocations, you should use R_PPC_EMB_SDA21, which the linker will fill in both the offset and the appropriate base register into the instruction. > ------- Additional Comment #6 From Mark Mitchell 2003-07-20 00:52 [reply] ------- > > Based on Franz's comments, this bug is not really a regression at all. > I've therefore removed the regression tags. > > that I've tried to explain in my comment #7. > > I don't think I need to file yet another PR in this situation, right? > > -- > Sergei. > -- Michael Meissner email: gnu@the-meissners.org http://www.the-meissners.org ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-21 9:55 ` Michael Meissner @ 2005-06-21 12:49 ` Sergei Organov 0 siblings, 0 replies; 17+ messages in thread From: Sergei Organov @ 2005-06-21 12:49 UTC (permalink / raw) To: Michael Meissner; +Cc: gcc, Andrew Pinski Michael Meissner <gcc-mail@the-meissners.org> writes: > On Mon, Jun 20, 2005 at 07:57:17PM +0400, Sergei Organov wrote: > > Andrew Pinski <pinskia@physics.uc.edu> writes: > > > > > On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote: > > > > > > > Andrew Pinski <pinskia@physics.uc.edu> 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. > > > > > > Could you file a bug? This is a target bug. > > > > Yeah, and I've reported it rather long ago against gcc-3.3 (PR 9571). > > That time there were 3 problems reported in the PR of which only the > > first one seems to be fixed (or are the rest just re-appeared in 4.0?). > > > > I think PR 9571 is in fact regression with respect to 2.95.x despite the > > [wrong] comments: > > > > ------- Additional Comment #5 From Franz Sirl 2003-06-17 15:31 [reply] ------- > > > > r0 is used as a pointer to sdata2, this is a bug, it should be r2. And > > since only r2 is initialized in the ecrt*.o files, how can this work? > > Besides that, even if you initialize r0 manually, it is practically > > clobbered in about every function. > > It's been a long time since I've hacked the PowerPC, but IIRC the instruction > set, a base register of '0' does not mean r0, but instead it means use 0 as the > base address. Every place that uses a base register should use the register > class 'b' (BASE_REGS) instead of 'r' (GENERAL_REGS), which excludes r0 from > being considered. > > Under the 32-bit eABI calling sequence, you have three small data areas: > > The small data area that r2 points to (.sdata/.sbss). > > The small data area that r13 points to (.sdata2/.sbss2). > > The small data area centered around location 0 (ie, small positive > addresses, and the most negative addresses). I don't recall that we > had special sections for this, since for many embedded apps, they > couldn't allocate to those addresses. > > For these relocations, you should use R_PPC_EMB_SDA21, which the > linker will fill in both the offset and the appropriate base register > into the instruction. Exactly, and that's what gcc actually and correctly does. My comment in the PR exactly matches what you've said above: ------- Additional Comment #7 From Sergei Organov 2003-10-14 14:42 [reply] ------- > r0 is used as a pointer to sdata2, this is a bug, it should be r2. No, the %r0 you see is fake. In the object file it's a special relocatable symbol that is resolved to either 2 (r2) or 13 (r13) by the linker depending on actual output section the symbol refers to, so there is no bug here. IMHO, the assembly output is just somewhat misleading mentioning %r0 in the place in question, -- it better should be just 0 I think as SYM@sda21(0) would create less confusion than SYM@sda21(%r0). On the other hand, I must admit the PR with item 1 (wrong section attribute) fixed is not a regression anymore. I apologize, but I've compared gcc-3.x/4.x with *patched* version of gcc-2.95.x that I've hacked to force it to put double/float constants into .sdata2 section. Now I've applied my hack to gcc-4.1.0 and get similar results, though the patch is indeed a hack and is not satisfactory. I think there is a fundamental problem that compiler-generated symbols referring to constants are generated too late, at RTL level, and thus aren't handled by the small section logic working on the tree level. Any thoughts? -- Sergei. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-20 15:36 ` Andrew Pinski 2005-06-20 15:58 ` Sergei Organov @ 2005-06-20 17:18 ` Sergei Organov 2005-06-24 16:09 ` Sergei Organov 2 siblings, 0 replies; 17+ messages in thread From: Sergei Organov @ 2005-06-20 17:18 UTC (permalink / raw) To: Andrew Pinski; +Cc: gcc Andrew Pinski <pinskia@physics.uc.edu> writes: > On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote: > > > Andrew Pinski <pinskia@physics.uc.edu> 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. Well, provided that: void default_elf_select_rtx_section (enum machine_mode mode, rtx x, unsigned HOST_WIDE_INT align) { /* ??? Handle small data here somehow. */ ... } is still there at varasm.c:5330, I don't think it's a target bug :( -- Sergei. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-20 15:36 ` Andrew Pinski 2005-06-20 15:58 ` Sergei Organov 2005-06-20 17:18 ` Sergei Organov @ 2005-06-24 16:09 ` Sergei Organov 2 siblings, 0 replies; 17+ messages in thread From: Sergei Organov @ 2005-06-24 16:09 UTC (permalink / raw) To: Andrew Pinski; +Cc: gcc Andrew Pinski <pinskia@physics.uc.edu> writes: > On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote: > > > Andrew Pinski <pinskia@physics.uc.edu> 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-20 14:04 ` Andrew Haley 2005-06-20 14:26 ` Andrew Pinski @ 2005-06-20 14:28 ` Sergei Organov 2005-06-22 19:29 ` Zack Weinberg 1 sibling, 1 reply; 17+ messages in thread From: Sergei Organov @ 2005-06-20 14:28 UTC (permalink / raw) To: Andrew Haley; +Cc: gcc Andrew Haley <aph@redhat.com> writes: > Sergei Organov writes: > > Hi, > > > > Using gcc compiled from gcc-4_0-branch, in an attempt to see which > > particular optimization option makes my test case to be mis-optimized, I > > try to replace -O1 (which toggles on the problem) with corresponding set > > of -fxxx optimization options. > > In general you can't do this. You can turn some optimization passes > off, though. Sigh :( > > > How one finds out what optimization pass misbehaves? > > Look at the dumps. If you use the gcc option -da you'll get a full > set of RTL dump files. I'm afraid that it's one of the tree optimization passes as const.cc.00.expand is already [mis]optimized the way I don't like. -- Sergei. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-20 14:28 ` Sergei Organov @ 2005-06-22 19:29 ` Zack Weinberg 0 siblings, 0 replies; 17+ messages in thread From: Zack Weinberg @ 2005-06-22 19:29 UTC (permalink / raw) To: Sergei Organov; +Cc: Andrew Haley, gcc Sergei Organov wrote: > Andrew Haley <aph@redhat.com> writes: > > >>Sergei Organov writes: >> > Hi, >> > >> > Using gcc compiled from gcc-4_0-branch, in an attempt to see which >> > particular optimization option makes my test case to be mis-optimized, I >> > try to replace -O1 (which toggles on the problem) with corresponding set >> > of -fxxx optimization options. >> >>In general you can't do this. You can turn some optimization passes >>off, though. > > > Sigh :( To be clear - there are a number of optimizations which have no corresponding -f switch, being enabled or disabled solely by "if (optimize)" constructs; the global 'optimize' flag is set by -On (n>0). Similarly, there are places where "if (optimize >= 2)" is the sole trigger. This could be construed a bug, and I do not think there would be objection to patches that add -f options for every such optimization. zw ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-20 13:40 How to replace -O1 with corresponding -f's? Sergei Organov 2005-06-20 14:04 ` Andrew Haley @ 2005-06-20 14:25 ` Scott Robert Ladd 2005-06-20 14:35 ` Andrew Pinski 2 siblings, 0 replies; 17+ messages in thread From: Scott Robert Ladd @ 2005-06-20 14:25 UTC (permalink / raw) To: Sergei Organov; +Cc: gcc Sergei Organov wrote: > Using gcc compiled from gcc-4_0-branch, in an attempt to see which > particular optimization option makes my test case to be mis-optimized, This sort of problem is exactly what my Acovea program was designed for; it will identify the pessimistic option by analyzing GCC's compilation of your code. http://acovea.coyotegulch.com ..Scott ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-20 13:40 How to replace -O1 with corresponding -f's? Sergei Organov 2005-06-20 14:04 ` Andrew Haley 2005-06-20 14:25 ` Scott Robert Ladd @ 2005-06-20 14:35 ` Andrew Pinski 2005-06-20 15:04 ` Sergei Organov 2 siblings, 1 reply; 17+ messages in thread From: Andrew Pinski @ 2005-06-20 14:35 UTC (permalink / raw) To: Sergei Organov; +Cc: gcc On Jun 20, 2005, at 9:38 AM, Sergei Organov wrote: > 2. The resulting assembly is different from what I get with -O1 and > doesn't contain the mis-optimization I'm trying to debug though it > doesn't seem to have anything to do with loops. For reference, the > code I'm trying to compile is: > > extern double const osv; > double const osv = 314314314; > double osvf() { return osv; } I don't see anything wrong with what it gives for -O0 and -O2. -- Pinski ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to replace -O1 with corresponding -f's? 2005-06-20 14:35 ` Andrew Pinski @ 2005-06-20 15:04 ` Sergei Organov 0 siblings, 0 replies; 17+ messages in thread From: Sergei Organov @ 2005-06-20 15:04 UTC (permalink / raw) To: Andrew Pinski; +Cc: gcc Andrew Pinski <pinskia@physics.uc.edu> writes: > On Jun 20, 2005, at 9:38 AM, Sergei Organov wrote: > > > 2. The resulting assembly is different from what I get with -O1 and > > doesn't contain the mis-optimization I'm trying to debug though it > > doesn't seem to have anything to do with loops. For reference, the > > code I'm trying to compile is: > > > > extern double const osv; > > double const osv = 314314314; > > double osvf() { return osv; } > > I don't see anything wrong with what it gives for -O0 and -O2. Well, it's on PowerPC with its small constant data sections. With -O1 I get: .globl osv .section .sdata2,"a",@progbits .align 3 .type osv, @object .size osv, 8 osv: .long 1102232590 .long 1241513984 .section .rodata.cst8,"aM",@progbits,8 .align 3 .LC0: .long 1102232590 .long 1241513984 .section ".text" .align 2 .globl osvf .type osvf, @function osvf: lis %r9,.LC0@ha # tmp121, lfd %f1,.LC0@l(%r9) #, <result> blr # With -O0 and a bunch of -f's from -O1 I get: .globl osv .section .sdata2,"a",@progbits .align 3 .type osv, @object .size osv, 8 osv: .long 1102232590 .long 1241513984 .section ".text" .align 2 .globl osvf .type osvf, @function osvf: .LFB2: lfd %f0,osv@sda21(%r0) # osv, D.1144 fmr %f1,%f0 # <result>, <result> blr # While the ideal code would be: ... osvf: .LFB2: lfd %f1,osv@sda21(%r0) # osv, D.1144 blr # -- Sergei. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2005-06-24 16:09 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-06-20 13:40 How to replace -O1 with corresponding -f's? Sergei Organov 2005-06-20 14:04 ` Andrew Haley 2005-06-20 14:26 ` Andrew Pinski 2005-06-20 14:55 ` Sergei Organov 2005-06-20 15:01 ` Andrew Pinski 2005-06-20 15:29 ` Sergei Organov 2005-06-20 15:36 ` Andrew Pinski 2005-06-20 15:58 ` Sergei Organov 2005-06-21 9:55 ` Michael Meissner 2005-06-21 12:49 ` Sergei Organov 2005-06-20 17:18 ` Sergei Organov 2005-06-24 16:09 ` Sergei Organov 2005-06-20 14:28 ` Sergei Organov 2005-06-22 19:29 ` Zack Weinberg 2005-06-20 14:25 ` Scott Robert Ladd 2005-06-20 14:35 ` Andrew Pinski 2005-06-20 15:04 ` Sergei Organov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).