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?
Thanks,
Bingfeng Mei
