Richard, Thanks. -fno-tree-ter does work around the problem. I did look at the info about coalescing, which doesn't give much info. I think I have to take a closer look at TER and coalescing algorithm.
Regards, Bingfeng > -----Original Message----- > From: Richard Guenther [mailto:richard.guent...@gmail.com] > Sent: 08 December 2011 12:10 > To: Bingfeng Mei > Cc: gcc@gcc.gnu.org; Michael Matz > Subject: Re: Bug in Tree to RTL expansion? > > On Thu, Dec 8, 2011 at 12:34 PM, Bingfeng Mei <b...@broadcom.com> wrote: > > Hi, > > I experienced a code generation bug with 4.5 (yes, our > > port is still stuck at 4.5.4). Since the concerned code > > is full of our target-specific code, it is not easy > > to demonstrate the error with x86 or ARM. > > > > Here is what happens in expanding process. The following is a > > piece of optimized tree code to be expanded to RTL. > > > > # ptr_h2_493 = PHI <ptr_h2_310(30), ptr_hf_465(29)> > > ... > > D.13598_218 = MEM[base: ptr_h2_493, offset: 8]; > > D.13599_219 = (long int) D.13598_218; > > ... > > ptr_h2_310 = ptr_h2_493 + 16; > > ... > > D.13634_331 = D.13599_219 * D.13538_179; > > cor3_332 = D.13635_339 + D.13634_331; > > ... > > > > When expanding to RTL, the coalescing algorithm will coalesce > > ptr_h2_310 & ptr_h2_493 to one register: > > > > ;; ptr_h2_310 = ptr_h2_493 + 16; > > (insn 364 363 0 (set (reg/v/f:SI 282 [ ptr_h2 ]) > > (plus:SI (reg/v/f:SI 282 [ ptr_h2 ]) > > (const_int 16 [0x10]))) -1 (nil)) > > > > GCC 4.5 (fp_gcc 2.3.x) doesn't expand statements one-by-one > > as GCC 4.4 (fp_gcc 2.2.x) does. So when GCC expands the > > following statement, > > > > cor3_332 = D.13635_339 + D.13634_331; > > > > it then in turn expands each operand by going back to > > expand previous relevant statements. > > > > D.13598_218 = MEM[base: ptr_h2_493, offset: 8]; > > D.13599_219 = (long int) D.13598_218; > > ... > > D.13634_331 = D.13599_219 * D.13538_179; > > > > The problem is that compiler doesn't take account into fact that > > ptr_h2_493|ptr_h2_310 has been modified. Still expand the above > > statement as it is. > > > > (insn 380 379 381 (set (reg:HI 558) > > (mem:HI (plus:SI (reg/v/f:SI 282 [ ptr_h2 ]) > > (const_int 8 [0x8])) [0 S2 A8])) -1 (nil)) > > ... > > (insn 382 381 383 (set (reg:SI 557) > > (mult:SI (sign_extend:SI (reg:HI 558)) > > (sign_extend:SI (reg:HI 559)))) -1 (nil)) > > > > This seems to me quite a basic issue. I cannot believe testsuites > > and other applications do not expose more errors. > > > > What I am not sure is whether the coalescing algorithm or the > expanding > > procedure is wrong here. If ptr_h2_493 and ptr_h2_310 are not > coalesced > > to use the same register, it should be correctly compiled. Or > expanding > > procedure checks data flow, it should be also OK. Which one should I > > I look at? Or is this a known issue and fixed in 4.6/4.7? > > TER should not happen for D.13598_218 = MEM[base: ptr_h2_493, offset: > 8]; because it conflicts with the coalesce. Thus, -fno-tree-ter > should > fix your issue. You may look at the -fdump-rtl-expand-details dump > to learn about the coalescing decisions. > > I'm not sure we fixed a bug that looks like the above. With 4.5 > the 'MEM' is a TARGET_MEM_REF tree. > > Micha should be most familiar with evolutions in this code. > > Richard. > > > Thanks, > > Bingfeng Mei > >
