This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Value numbering and volatility


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.



> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]