[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.
rguenth at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Wed Nov 2 13:10:00 GMT 2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-11-02 13:09:40 UTC ---
It looks like IVOPTs fails to consider a candidate for the use inquestion
and thus, after choosing the final IV set ends up rewriting that use into
this stupid form (instead of using candidate 0). The use is
use 3
generic
in statement vect_p.60_223 = PHI <vect_p.60_224(16), vect_p.63_222(5)>
at position
type vector(8) unsigned char *
base batmp.61_221 + 1
step 8
base object (void *) batmp.61_221
is a biv
related candidates
but costs say:
Use 3:
cand cost compl. depends on
0 8 1 inv_expr:0
1 4 1 inv_expr:1
2 4 1 inv_expr:0
3 4 1 inv_expr:1
4 4 1 inv_expr:2
Initial set of candidates:
cost: 24 (complexity 4)
cand_cost: 10
cand_use_cost: 10 (complexity 4)
candidates: 0, 4
use:0 --> iv_cand:4, cost=(2,1)
use:1 --> iv_cand:4, cost=(2,1)
use:2 --> iv_cand:4, cost=(2,1)
use:3 --> iv_cand:4, cost=(4,1)
use:4 --> iv_cand:0, cost=(0,0)
invariants 7
Selected IV set:
candidate 0 (important)
var_before ivtmp.107_150
var_after ivtmp.107_256
incremented before exit test
type unsigned int
base 0
step 1
candidate 4 (important)
var_before ivtmp.110_241
var_after ivtmp.110_146
incremented before exit test
type unsigned int
base (unsigned int) (&p1 + 8)
step 8
base object (void *) &p1
so expressing use 3 with candidate 4 is cheaper than with candidate 0...
Now, for address-uses we have
if (address_p)
{
/* Do not try to express address of an object with computation based
on address of a different object. This may cause problems in rtl
level alias analysis (that does not expect this to be happening,
as this is illegal in C), and would be unlikely to be useful
anyway. */
if (use->iv->base_object
&& cand->iv->base_object
&& !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0))
return infinite_cost;
in cost calculation, but in this case it's a nonlinear use, and we have
(gdb) call debug_generic_expr (use->iv->base_object)
(void *) batmp.61_221
(gdb) call debug_generic_expr (cand->iv->base_object)
(void *) &p1
More information about the Gcc-bugs
mailing list