This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Value numbering and volatility
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Eric Botcazou <ebotcazou at adacore dot com>, gcc at gcc dot gnu dot org
- Date: Wed, 21 Jun 2006 10:56:30 -0400
- Subject: Re: Value numbering and volatility
- References: <200606211605.20877.ebotcazou@adacore.com> <44995A0B.5080805@redhat.com>
Diego Novillo wrote:
> Eric Botcazou wrote on 06/21/06 10:05:
>
>> It seems to me that the volatility should be accounted for in the VALUE_HANDLE
>> itself only, not in (de)references to it.
>>
> As Richard and Andrew pointed out, the bug is that we try to compute the
> value number of a statement with volatile references in it. If the
> statement is not marked as having volatile references, then it should
> be. If the value numbering routines are not checking for volatility,
> then they should be.
If the statement has volatile ops, we just give the defs the statement
makes (not the virtual defs) unique value numbers, as we should :)
if (TREE_CODE (stmt) == MODIFY_EXPR
&& !ann->has_volatile_ops
{
...
}
else
{
/* For any other statement that we don't recognize, simply
make the names generated by the statement available in
AVAIL_OUT and TMP_GEN. */
FOR_EACH_SSA_TREE_OPERAND (op, stmt, iter, SSA_OP_DEF)
add_to_sets (op, op, NULL, TMP_GEN (block), AVAIL_OUT (block));
FOR_EACH_SSA_TREE_OPERAND (op, stmt, iter, SSA_OP_USE)
add_to_sets (op, op, NULL, NULL , AVAIL_OUT (block));
}
Since he's showing us a indirect store or load (which won't show up in
the defs list of a statement) being value numbered, the statement must
not be marked has_volatile_ops properly.
>