http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49937
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Component|middle-end |tree-optimization
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-09
12:19:20 UTC ---
The folding happens (and is supposed to happen) in CCP for x86_64 (that was
the idea when removing the forwprop duplicate, which has correctness issues,
instead of "fixing" it).
CCP uses get_value_from_alignment, the difference between x86_64 and the
cross is:
Visiting statement:
D.2090_3 = (long int) foo;
which is likely CONSTANT
Lattice value changed to CONSTANT Lattice value changed to CONSTANT
0x00000000000000000 (0xfffffffffffffffffffffffffffffffe). Adding SSA edges to
worklist.
Visiting statement:
D.2091_4 = D.2090_3 & 1;
which is likely CONSTANT
Lattice value changed to CONSTANT 0. Adding SSA edges to worklist.
vs. cris:
Visiting statement:
D.1722_3 = (long int) foo;
which is likely CONSTANT
Lattice value changed to VARYING. Adding SSA edges to worklist.
Visiting statement:
D.1723_4 = D.1722_3 & 1;
which is likely CONSTANT
Lattice value changed to CONSTANT Lattice value changed to CONSTANT
0x00000000000000000 (0x00000000000000001). Adding SSA edges to worklist.
which is because
else if (base
&& ((align = get_object_alignment (base, BIGGEST_ALIGNMENT))
> BITS_PER_UNIT))
even though the FUNCTION_DECL has align 16, BIGGEST_ALIGNMENT is 8 on cris
(which means we can't rely on any DECL_ALIGN or other stuff
get_object_alignment
uses if it is bigger than that value?).
Thus, the get_object_alignment_1 hunk
if (DECL_P (exp)
&& TREE_CODE (exp) != LABEL_DECL)
{
if (TREE_CODE (exp) == FUNCTION_DECL)
{
/* Function addresses can encode extra information besides their
alignment. However, if TARGET_PTRMEMFUNC_VBIT_LOCATION
allows the low bit to be used as a virtual bit, we know
that the address itself must be 2-byte aligned. */
if (TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_pfn)
align = 2 * BITS_PER_UNIT;
else
align = BITS_PER_UNIT;
}
is non-functional for cris.
>From looking at the docs for BIGGEST_ALIGNMENT I wonder why we use that
for all callers of get_object_alignment and not, for example,
MAX_OFILE_ALIGNMENT?
CCP certainly doesn't care - as long as it can trust the value returned.
CCP wants to use get_object_alignment_1 anyway.
hp, can you maybe answer the question about correctness for aligns
bigger than BIGGEST_ALIGNMENT? And eventually audit other callers?
